samba - Sep 2017 - dfs links anywhere?

> 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)