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.
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.
Please also try v4.13 as it contains the change 6e3c1529c39e92ed64ca41d53abadabbaa1d5393
Created attachment 258363 [details] CIFS queries and responses during mount
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.
That is SMB1. Can you try with a SMB2 mount too?
Created attachment 258383 [details] SMB2.0 fs attr info query & response
Created attachment 258385 [details] SMB2.1 fs attr info query & response
Created attachment 258387 [details] SMB3.0 fs attr info query & response
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.
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.
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:
This is fixed with 4.14.3. I'm guessing f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 is what did it. Thanks!