(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)
Hi again, I had a look at your hunch and it seems to be fruitful: This link style allows following the DFS link with cifs.ko: ln -s msdfs://smb03.physics.wisc.edu/share/path testforward BUT this link style (from Samba Wiki[1]) does NOT work: ln -s msdfs:smb03.physics.wisc.edu\\share\\path testback Thanks for you help! C. [1] Samba Wiki https://wiki.samba.org/index.php/Distributed_File_System_(DFS)
Hi Chad, Sorry for the late reply. Looking at this now. Chad William Seys <cwseys at physics.wisc.edu> writes:> I've attached traces and logs of these situations: > > msdfs root = yes, link points to share, link CAN be followed > trace_msdfsrootyes_share.* > > msdfs root = yes, link points to path, link CANNOT be followed > trace_msdfsrootyes_path.*In this one I still see things mixing directory separators, e.g.: Update attributes: //smb03.physics.wisc.edu/smb\instr_files inode 0xffff893c53c0e0a8 count 1 dentry: 0xffff893c596bbd80 d_time 0 jiffies 5742081270 What about making your symlink like this: ln -s 'msdfs:\\smb03.physics.wisc.edu\share\path' testback Note the use of simple quote and double _back_slash. I get unexpected result with zsh (\ gets interpreted..) but with bash it results in this: d55:/tmp/share # ls -l link* lrwxrwxrwx 1 aaptel users 28 Aug 30 16:51 link -> msdfs:\\10.160.65.191\target lrwxrwxrwx 1 aaptel users 32 Aug 30 16:50 linksub -> msdfs:\\10.160.65.191\target\sub And both link works, with msdfs root = yes> msdfs root = no, link points to path, link CAN be followed > trace_msdfsrootno_path.*-- 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)
Good news! Kernel 4.13 can resolve either style of link, so I don't think we need to spend more time with it! gvfs in Debian 9 also works (as do Windows 7+ and Mac 10.12+). What does not work is Debian's 4.9.30-2+deb9u3 and Centos 7 3.10.0-514.26.2 If anyone could point out the patch which fixed this, possibly it could be backported.... Thanks! Chad.
Hi Aurélien,
Thanks for the continued help!
I created the links as you suggested. Similar to before, the link
to the share works, but the link to the directory in the share does not
work.
# to share
ln -sf 'msdfs:\\smb03.physics.wisc.edu\smb' smb03_smb
# to directory in share
ln -sf 'msdfs:\\smb03.physics.wisc.edu\smb\instr_files'
smb03_smb_instrfiles
I still see the mixed / \ in the logs (attached).
Chad.
P.S. As a reminder, we've also tried the below variant with the same result:
# to share
ln -sf msdfs://smb03.physics.wisc.edu/smb smb03_smb
# to directory in share
ln -sf msdfs://smb03.physics.wisc.edu/smb/instr_files smb03_smb_instrfiles
Chad William Seys <cwseys at physics.wisc.edu> writes:> Kernel 4.13 can resolve either style of link, so I don't think we need > to spend more time with it! > gvfs in Debian 9 also works (as do Windows 7+ and Mac 10.12+).Good. I actually remember fixing something similar now, ha. If you cannot update your kernel I think disabling the unix extension might be a workaround (-o nounix). It will force the use of backslashes. -- 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)