kernel 4.4.0.97.102 breaks DFS

[Juriaan Bakx]

OS: Ubuntu Desktop 16.04.3

We connect to Windows DFS using automounter with our Linux 16.04 workstations to let users access the windows shares. Until kernel version 4.4.0-96 this worked without any issues. However if a computer updates to kernel 4.4.0.97.102, using the same configs and samba version, it stops working and reports a "ls: cannot access xx: File name too long" error. (where xx is a foldername)

Also if you run "ls -all" you will see:

d????????? ? ? ? ? ? Applications

on the same computer selecting kernel 4.4.0.21.22 at grub menu:

drwx--x--x 2 root root 0 Oct 20 16:44 Applications

Mount commando output (removed hostnames and IP numbers ) on computer with kernel 4.4.0.21.22

//XXX/Public on /vol/winshare/Public type cifs (rw,relatime,vers=1.0,sec=krb5,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=x.x.x.x file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=61440,wsize=65536,actimeo=1)

Mount commando output (removed hostnames and IP numbers ) on the same computer with kernel 4.4.0.97.102

//XXX/Public on /vol/winshare/Public type cifs (rw,relatime,vers=1.0,sec=krb5,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=x.x.x.x,file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

During these tests the only thing that changed is the running kernel, no other changes were applied.

autofs config file used for this connection

Public -fstype=cifs,sec=krb5,multiuser,nounix,noserverino ://<servername>/Public

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Ever since updating to 4.12.10, I have been getting "File name too long" messages when accessing my CIFS share:

  $ ls /nfs/users/test
  ls: cannot access '/nfs/users/test': File name too long

On my system, the CIFS share is mounted on /nfs/users. (An NFS export was transitioned to CIFS a while back, hence the oddly named mount point.)

This issue goes away if I revert to 4.12.8. Commit d3edede looks relevant.

[lsahlber (lsahlber-linux-kernel-bugs)]

Which architecture do you see this on?

Can you attach a network trace including the initial mount, i.e. the query calls where cifs.ko will discover what the maximum length the server supports
during the mount.

[lsahlber (lsahlber-linux-kernel-bugs)]

Please also try v4.13 as it contains the change 6e3c1529c39e92ed64ca41d53abadabbaa1d5393

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Created attachment 258363
CIFS queries and responses during mount

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Both server and client are x86_64. Server is samba 4.6.7.

I've attached a trace excerpt showing the queries and responses during mount. The very last message shows the server responding with max length 255.

The issue persists with 4.12.12, which includes 77ab9e7fb4312d3b377690660f757d900fa9e171, which I believe is the same as the change you mention above.

[lsahlber (lsahlber-linux-kernel-bugs)]

That is SMB1. Can you try with a SMB2 mount too?

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Created attachment 258383
SMB2.0 fs attr info query & response

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Created attachment 258385
SMB2.1 fs attr info query & response

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Created attachment 258387
SMB3.0 fs attr info query & response

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

Same result with SMB2.0, SMB2.1, and SMB3.0. I've attached traces of the FileFsAttributeInformation queries and responses for all three protocol versions.

[lsahlber (lsahlber-linux-kernel-bugs)]

I can not reproduce this issue using current linux/master branch.

The queries look sane in the network trace so ...

What fileserver are you using? Windows or Samba? And what version.
Can you try using the same kernel and try accessing a different share on a different file server to see if things are different.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1725322/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream stable kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.4 stable kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.93

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

The server is Samba 4.6.7. Users are stored in LDAP and authenticated with Kerberos. Here are the mount options I am using:

  user=machine-root,multiuser,sec=krb5,x-systemd.automount

Unfortunately, I don't have a different file server to play with, but I suspect it is the 'multiuser' option that is breaking things.

Here are the contents of /proc/fs/cifs/DebugData after the initial mount:

  Display Internal CIFS Data Structures for Debugging
  ---------------------------------------------------
  CIFS Version 2.09
  Features: dfs fscache posix spnego xattr acl
  Active VFS Requests: 0
  Servers:
  Number of credits: 17
  1) entry for SERVER_IP not fully displayed
        TCP status: 1
        Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0
        Shares:
        1) \\SERVER_NAME\users Mounts: 1 DevInfo: 0x20 Attributes: 0x1006f
        PathComponentMax: 255 Status: 1 type: DISK
        Share Capabilities: None Aligned, Partition Aligned, Share Flags: 0x0 Optimal sector size: 0x200

        MIDs:

And here it is again after I try to `ls /nfs/users/test` as a normal user:

  Display Internal CIFS Data Structures for Debugging
  ---------------------------------------------------
  CIFS Version 2.09
  Features: dfs fscache posix spnego xattr acl
  Active VFS Requests: 0
  Servers:
  Number of credits: 20
  1) entry for SERVER_IP not fully displayed
        TCP status: 1
        Local Users To Server: 2 SecMode: 0x1 Req On Wire: 0
        Shares:
        1) \\SERVER_NAME\users Mounts: 1 DevInfo: 0x0 Attributes: 0x0
        PathComponentMax: 0 Status: 1 type: 0
        Share Capabilities: None Share Flags: 0x0

        MIDs:

  1) entry for SERVER_IP not fully displayed
        TCP status: 1
        Local Users To Server: 2 SecMode: 0x1 Req On Wire: 0
        Shares:
        1) \\SERVER_NAME\users Mounts: 1 DevInfo: 0x20 Attributes: 0x1006f
        PathComponentMax: 255 Status: 1 type: DISK
        Share Capabilities: None Aligned, Partition Aligned, Share Flags: 0x0 Optimal sector size: 0x200

        MIDs:

[Juriaan Bakx (j-bakx)]

user@somecomputer:/vol/winshare/Public$ ls -all
ls: cannot access 'Applications': File name too long

uname -r
4.4.93-040493-generic

[Juriaan Bakx (j-bakx)]

Also fails with kernel 4.4.94-040494-generic

[Juriaan Bakx (j-bakx)]

mounting on a computer running 4.4.0-97 with automounter still gives "error cannot access xx: File name too long" but when using gvfs-mount it works perfectly.

[Juriaan Bakx (j-bakx)]

Interestingly when running sudo ls, using the machine keytab, is works. So looks for me the problem is somewhere in the user kerberos ticket. Still this only happens with kernels released after 4.4.0-96

[Juriaan Bakx (j-bakx)]

That last sentence was incorrect, Instead of "Still this only happens with kernels released after 4.4.0-96" you should read Still this only happens with kernels released after 4.4.0-92"

[jed-kernel.org (jed-kernel.org-linux-kernel-bugs)]

This is fixed with 4.14.3. I'm guessing f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 is what did it. Thanks!