> Which smb version are you using (mount option)? Support for DFS on smb2+ > was only added in linux 4.11.smbstatus shows the connection as NT1. DFS links do work like this: serverA_msdfsrootYES => serverB_msdfsrootNO But not like this: serverA_msdfsrootYES => serverB_msdfsrootYES Somehow the destination having 'msdfsroot yes' prevents the cifs kernel module from following the link. Thanks! C.
Chad William Seys <cwseys at physics.wisc.edu> writes:> Somehow the destination having 'msdfsroot yes' prevents the cifs kernel > module from following the link.Could you provide a network trace from the linux client of you mounting and accessing this multi-level target, along with verbose kernel logs? echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control echo 1 > /proc/fs/cifs/cifsFYI echo 1 > /sys/module/dns_resolver/parameters/debug dmesg --clear tcpdump -w trace.pcap & pid=$! sleep 3 mount.cifs ....cd ... ls.. blahblah sleep 3 kill $pid dmesg > trace.log this should produce a trace.pcap and trace.log file. -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
(Let's keep this on the list) Aurélien Aptel via samba <samba at lists.samba.org> writes:> Chad William Seys <cwseys at physics.wisc.edu> writes: >> Somehow the destination having 'msdfsroot yes' prevents the cifs kernel >> module from following the link.I've taken a look at your traces and right off the bat I see things like this: [...] /linux-4.9.30/fs/cifs/smb1ops.c: cifs_query_symlink: target path: \smb03.physics.wisc.edu\smb\instr_files [...] /linux-4.9.30/fs/cifs/link.c: CIFS VFS: leaving cifs_get_link (xid = 35208) rc = 0 [...] /linux-4.9.30/fs/cifs/dir.c: CIFS VFS: in cifs_lookup as Xid: 35209 with uid: 1494 [...] /linux-4.9.30/fs/cifs/dir.c: parent inode = 0xffff893b14d610a8 name is: \smb03.physics.wisc.edu\smb\instr_files and dentry = 0xffff893b79dda3c0 [...] /linux-4.9.30/fs/cifs/dir.c: name: /\smb03.physics.wisc.edu\smb\instr_files [...] /linux-4.9.30/fs/cifs/dir.c: name: /itadmin/\smb03.physics.wisc.edu\smb\instr_files [...] /linux-4.9.30/fs/cifs/dir.c: NULL inode in lookup [...] /linux-4.9.30/fs/cifs/dir.c: Full path: smb.physics.wisc.edu/smb/itadmin\smb03.physics.wisc.edu\smb\instr_files inode = 0x (null) Note the weird looking path: smb.physics.wisc.edu/smb/itadmin\smb03.physics.wisc.edu\smb\instr_files Look to me the link is not properly substituted and there might some issues with Unix Extensions mixing path separators. I couldn't reproduce this on recent master kernel but I'll give it a try on v4.9 which you seem to be using. My setup is cifs.ko connecting to sambaA/shareA -> sambaB/shareB -> sambaB/shareC using unix extensions and both servers having 'msdfs host = yes' and shareA, shareB with 'msdfs root = yes'. Also, how did you create your symbolic links on the samba machine? (exact command). Just a hunch at this point but you might want to check you properly used _two_ backslashes at the start of the link target. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)