The Samba-Bugzilla – Bug 5641
Can't use Samba server as DFS host via dfsgui.msc
Last modified: 2009-08-11 04:13:26 UTC
I tried to create a DFS root in my 2003 AD domain and point it to a share hosted on a Samba server. From the documentation, I thought that this was supported (msdfs host = yes ?). This is with Samba 3.0.31 on RHEL 5 x86. The domain controllers are MS 2003 SP2, all in native-2003 mode. I also tried with samba 3.0.28 with the same result.
When I go to create the DFS root (via the msc plugin) and instruct it to use my samba machine as the host, I get this error:
"The computer you entered cannot host the DFS root. You must enter the name of a computer running an operating system in the Windows 2000 Server or Windows Server 2003 families."
Just to be clear, I'm NOT trying to make Samba a DFS root, just a host (ie target) for a DFS root that will exist on the AD domain.
Created attachment 3427 [details]
tcpdump trace of the client-server communication
Created attachment 3428 [details]
level 10 debug log from smbd of client-server comminucation
Can you please upload the dump again, this time with full packets? You can make tcpdump dump more with -s 1500 or -s 0.
Created attachment 3429 [details]
tcpdump trace of the client-server communication with full packets
Thanks. It would be great if you could send a comparative trace of the same call against a working Windows DFS target. I suspect that the bitmask sent in the Server Type field of frame 33 matters, I would like to see what a working box sends. As a simple patch we could just send back the same bitmask and see how far we come then.
Created attachment 3430 [details]
comparative trace of the same call against windows machine
This is against Windows 2003R2 SP2.
There are some bits different. If the wireshark descriptions are correct, the only strange one is that samba says it's Xenix. Another strange thing is that samba says it is a domain member and windows does not (but it definitely is).
Another possibility could be that the msc wants major version >= 5 ?
Oh, the version is easy to test: "announce version = 5.2".
Created attachment 3439 [details]
level 10 debug log showing 2nd failure type
Ok, that was easy! Setting 'announce version' to 5.x makes that step work.
Now however, when I get to the last step and click finish I get a new error: "The stub received bad data."
Looking at the debug log, I believe this is where it dies:
api_rpcTNP: netdfs op 0xa - api_rpcTNP: rpc command: DFS_ADDFTROOT
api_rpc_cmds.fn == 0x8665d0
0000 status: WERR_NOT_SUPPORTED
api_rpcTNP: called netdfs successfully
api_rpcTNP: rpc input buffer underflow (parse error?)
I will upload network traces in a sec.
Created attachment 3440 [details]
network trace against samba of failing 2nd step
Created attachment 3441 [details]
working network trace against windows for compairison.
This trace is a start to finish of the whole process.
Ah yes. We seem to be here:
WERROR _dfs_AddFtRoot(pipes_struct *p, NETDFS_Q_DFS_ADDFTROOT *q_u, NETDFS_R_DFS_ADDFTROOT *r_u)
/* FIXME: Implement your code here */
So I guess this issue is going to be more of an RFE than a bug.
The good news is that all these info levels are now documented, so we can take a look at adding this in a reasonable timeframe.
Jeremy, any update on this bug ?