[Samba] msdfs root -- client error "refers to a location that isunavailable"

[Paul B. Henson]

I still haven't been able to figure this out; and haven't seen any
responses to my inquiry. One of my colleagues wanted to host the Dfs root
on an actual Windows server, which seems to work fine. I was hoping to keep
an all Samba solution, but I guess I will have to let him have his way.

Clearly samba Dfs root support works for some people; it is rather
frustrating that it's not working here for no apparent reason.


On Tue, 11 Mar 2008, Paul B. Henson wrote:

> I'm trying to get Samba 3.0.28 to work as an MS Dfs root providing a
> share that links home directories to the actual servers they reside on.
>
> Unfortunately, when I access the share from a Windows XP client, and try
> to open one of the directories, the client gives an error that it "refers
> to a location that is unavailable".
>
> I've done a lot of searching, and found a number of similar issues
> raised, but sadly no real resolutions.
>
> Samba was attached to our active directory domain with "net ads join",
> which worked perfectly and authentication seems fine.
>
> My configuration is as follows:
>
> -----
> [global]
>         allow trusted domains = no
>         deadtime = 10
>         debug pid = yes
>         disable netbios = yes
>         lanman auth = no
>         load printers = no
>         log level = 1
>         map archive = no
>         name resolve order = host
>         passdb backend = tdbsam
>         realm = WIN.CSUPOMONA.EDU
>         restrict anonymous = 2
>         security = ads
>         server signing = auto
>         show add printer wizard = no
>         smb ports = 445
>         workgroup = WIN
>         max log size = 512000
>
> [user]
>         msdfs root = yes
>         path = /var/lib/samba/shares/user
> -----
>
> I'm only running smbd, not nmbd, as I don't want to use NetBIOS naming. The
> server is being accessed with a fully qualified name
> '\\files.unx.csupomona.edu\user'.
>
> In the configured share directory, I made a symbolic link as documented:
>
> lrwxrwxrwx 1 root root 35 Mar 10 16:26 henson -> msdfs:zfs1.unx.csupomona.edu\henson
>
>
> I'm pretty sure the Samba configuration itself is okay, accessing the share
> with smbclient works correctly and appropriately follows the link.
>
>
> With debugging enabled, I also see the following message logged:
>
> [2008/03/11 15:10:29, 5, pid=28793] smbd/msdfs.c:is_msdfs_link(337)
>   is_msdfs_link: ./henson -> msdfs:zfs1.unx.csupomona.edu\henson
>
>
> When I try to access it from a Windows client though, I do see this in the
> debug log:
>
> [2008/03/11 15:16:19, 5, pid=28904]
> smbd/trans2.c:get_lanman2_dir_entry(1215)
>   get_lanman2_dir_entry: Masquerading msdfs link ./henson as a directory
>
>
> I'm not sure that's normal, but seems odd. I'm not sure what all to attach
> from the debug log, it is rather large. The following seems associated with
> that request though:
>
>
>   size=86
>   smb_com=0x32
>   smb_rcls=0
>   smb_reh=0
>   smb_err=0
>   smb_flg=24
>   smb_flg2=51207
>   smb_tid=1
>   smb_pid=3264
>   smb_uid=103
>   smb_mid=2432
>   smt_wct=15
>   smb_vwv[ 0]=   18 (0x12)
>   smb_vwv[ 1]=    0 (0x0)
>   smb_vwv[ 2]=   10 (0xA)
>   smb_vwv[ 3]=16384 (0x4000)
>   smb_vwv[ 4]=    0 (0x0)
>   smb_vwv[ 5]=    0 (0x0)
>   smb_vwv[ 6]=    0 (0x0)
>   smb_vwv[ 7]=    0 (0x0)
>   smb_vwv[ 8]=    0 (0x0)
>   smb_vwv[ 9]=   18 (0x12)
>   smb_vwv[10]=   68 (0x44)
>   smb_vwv[11]=    0 (0x0)
>   smb_vwv[12]=    0 (0x0)
>   smb_vwv[13]=    1 (0x1)
>   smb_vwv[14]=    1 (0x1)
>   smb_bcc=21
>
>
> I think the following messages correspond to the error I am receiving from
> the client:
>
>
> [2008/03/11 15:16:26, 3, pid=28904]
> smbd/trans2.c:call_trans2qfilepathinfo(3292)
>   call_trans2qfilepathinfo: SMB_VFS_STAT of henson failed (No such file or
> directory)
> [2008/03/11 15:16:26, 3, pid=28904] smbd/error.c:unix_error_packet(56)
>   unix_error_packet: error string = No such file or directory
> [2008/03/11 15:16:26, 3, pid=28904] smbd/error.c:error_packet_set(106)
>   error packet at smbd/trans2.c(3293) cmd=50 (SMBtrans2)
> NT_STATUS_OBJECT_NAME_NOT_FOUND
>
> I think these are the flags relevant to that transaction:
>
>   size=90
>   smb_com=0x32
>   smb_rcls=0
>   smb_reh=0
>   smb_err=0
>   smb_flg=24
>   smb_flg2=51207
>   smb_tid=1
>   smb_pid=3264
>   smb_uid=103
>   smb_mid=3841
>   smt_wct=15
>   smb_vwv[ 0]=   22 (0x16)
>   smb_vwv[ 1]=    0 (0x0)
>   smb_vwv[ 2]=    2 (0x2)
>   smb_vwv[ 3]=   40 (0x28)
>   smb_vwv[ 4]=    0 (0x0)
>   smb_vwv[ 5]=    0 (0x0)
>   smb_vwv[ 6]=    0 (0x0)
>   smb_vwv[ 7]=    0 (0x0)
>   smb_vwv[ 8]=    0 (0x0)
>   smb_vwv[ 9]=   22 (0x16)
>   smb_vwv[10]=   68 (0x44)
>   smb_vwv[11]=    0 (0x0)
>   smb_vwv[12]=    0 (0x0)
>   smb_vwv[13]=    1 (0x1)
>   smb_vwv[14]=    5 (0x5)
>   smb_bcc=25
>
>
> Any ideas what's going on? In previous postings regarding this type of
> problem, it sounds like the Windows client is somewhat nondeterministic in
> whether or not it is willing to treat a given share as a DFS root?
>
> Any suggestions for additional debugging data that might be provided to
> further isolate the issue?
>
> Thanks much for any assistance...
>
>
>

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768