CIFS mounts fail with kernel-3.17.2-200.fc20.x86_64. A switch back to kernel-3.16.7-200.fc20.x86_64 solves the problem. Steps to reproduce: [root@myserver ~]# mount -v -t cifs -o rw,uid=myuser,gid=myuser,credentials=/etc/cred.txt //otherserver/mountdir /mnt/mymount mount.cifs kernel mount options: ip=192.168.1.1,unc=\\otherserver\mountdir,uid=1000,gid=1000,user=nas,pass=******** mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) [root@myserver ~]# /var/log/messages: Nov 13 12:15:43 myserver su: (to root) myuser on pts/0 Nov 13 12:15:56 myserver kernel: [ 67.957537] FS-Cache: Loaded Nov 13 12:15:56 myserver kernel: FS-Cache: Loaded Nov 13 12:15:56 myserver kernel: [ 67.959309] Key type dns_resolver registered Nov 13 12:15:56 myserver kernel: Key type dns_resolver registered Nov 13 12:15:57 myserver kernel: [ 67.971944] FS-Cache: Netfs 'cifs' registered for caching Nov 13 12:15:57 myserver kernel: [ 67.972126] Key type cifs.spnego registered Nov 13 12:15:57 myserver kernel: [ 67.972136] Key type cifs.idmap registered Nov 13 12:15:57 myserver kernel: FS-Cache: Netfs 'cifs' registered for caching Nov 13 12:15:57 myserver kernel: Key type cifs.spnego registered Nov 13 12:15:57 myserver kernel: Key type cifs.idmap registered Nov 13 12:15:57 myserver kernel: [ 68.005605] CIFS VFS: cifs_mount failed w/return code = -13 Nov 13 12:15:57 myserver kernel: CIFS VFS: cifs_mount failed w/return code = -13 Again, booting to the previous kernel gives a valid mount. I did an rsync with about 6 files and they are all fine. Thanks!
Same here after the upgrade. Samba version on the server side: samba-3.0.33-3.39.el5_8.x86_64
Just tried this with kernel-3.17.3-200.fc20.x86_64 and got the same results. [root@myserver ~]# mount -v -t cifs -o rw,uid=myuser,gid=myuser,credentials=/etc/cred.txt //otherserver/mountdir /mnt/mymount/ mount.cifs kernel mount options: ip=192.168.1.1,unc=\\otherserver\mountdir,uid=1000,gid=1000,user=nas,pass=******** mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) /var/log/messages: Nov 21 09:37:59 myserver su: (to root) myuser on pts/0 Nov 21 09:38:17 myserver fprintd: ** Message: No devices in use, exit Nov 21 09:40:16 myserver kernel: [ 262.544559] FS-Cache: Loaded Nov 21 09:40:16 myserver kernel: FS-Cache: Loaded Nov 21 09:40:16 myserver kernel: [ 262.546073] Key type dns_resolver registered Nov 21 09:40:16 myserver kernel: Key type dns_resolver registered Nov 21 09:40:16 myserver kernel: [ 262.555287] FS-Cache: Netfs 'cifs' registered for caching Nov 21 09:40:16 myserver kernel: [ 262.555483] Key type cifs.spnego registered Nov 21 09:40:16 myserver kernel: [ 262.555492] Key type cifs.idmap registered Nov 21 09:40:16 myserver kernel: FS-Cache: Netfs 'cifs' registered for caching Nov 21 09:40:16 myserver kernel: Key type cifs.spnego registered Nov 21 09:40:16 myserver kernel: Key type cifs.idmap registered Nov 21 09:40:16 myserver kernel: [ 262.588450] CIFS VFS: cifs_mount failed w/return code = -13 Nov 21 09:40:16 myserver kernel: CIFS VFS: cifs_mount failed w/return code = -13 This is working in kernel-3.16.7-200.fc20.x86_64. Samba is samba-4.1.12-5.fc20.x86_64.
I have tried to reproduce the problem but am unable to do so. Can you please provide me with a tcpdump each of the working and not working cases so that I can compare to try and determine what changed. Also cifs debug messages for the failed case could be useful. To generate those, run # echo 7 >/proc/fs/cifs/cifsFYI run the mount command The debug messages will be available in the dmesg. Simply provide me with the output of the dmesg command. Sachin Prabhu
(In reply to Sachin Prabhu from comment #3) > I have tried to reproduce the problem but am unable to do so. Can you please > provide me with a tcpdump each of the working and not working cases so that > I can compare to try and determine what changed. > I am not familiar with tcpdump. Can you be more specific, i.e, tell me which commands you wish me to run?
For 3.17.3-200: # echo 7 >/proc/fs/cifs/cifsFYI -bash: /proc/fs/cifs/cifsFYI: No such file or directory
Created attachment 960002 [details] Requested tcpdump pcap files and dmesg log I think this is what you want. I can try again if this is insufficient. I used this page to get the tcpdump information: https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
Hello Jerry, Thanks for the tcpdumps. Looking at the traces, there appears to be a difference in the UIDs set in the header. This change was introduced by code to cleanup and simplify the authentication code. I am trying to reproduce this on my test machines following which I'll write a patch to fix the issue. Sachin Prabhu
Created attachment 961260 [details] Proposed patch From edc0216ca23ed651ecfecd02d864e832b3f75e41 Mon Sep 17 00:00:00 2001 From: Sachin Prabhu <sprabhu> Date: Tue, 25 Nov 2014 15:11:36 +0000 Subject: [PATCH] Set UID in sess_auth_rawntlmssp_authenticate too A user complained that they were unable to login to their cifs share after a kernel update. From the wiretrace we can see that the server erturns different UIDs as response to NTLMSSP_NEGOTIATE and NTLMSSP_AUTH phases. With changes in the authentication code, we no longer set the cifs_sess->Suid returned in response to the NTLM_AUTH phase. We continue to use the UID sent in response to the NTLMSSP_NEGOTIATE phase. This results in an access being denied when connecting to a tree. Signed-off-by: Sachin Prabhu <sprabhu>
Hello Jerry, I was unable to reproduce it internally as you have on your setup. Can you please test this new kernel at http://people.redhat.com/sprabhu/bz1167970/ This is the standard kernel-3.17.2-200 with the patch from c#8. Can you give me a new tcpdump irrespective if it is working or no. If it doesn't work, I can use it to determine if something else is needed. If it does, I can use it to confirm that the UID issue was indeed the problem. Sachin Prabhu
Created attachment 963059 [details] tcpdump with patched kernel (successful mount) Mounting my CIFS share was successful with this patched kernel. Attached is the requested tcpdump.
Thanks Jerry, From the tcpdump I can confirm that the server first returns UID=100 in response to NTLMSSP_NEGOTIATE. Subsequently as a response to NTLMSSP_CHALLENGE, the UID is set to 101. The patched kernel uses this new UID and starts using it in the subsequent operations as expected. My next step is to push a patch upstream with this fix. Sachin Prabhu
Update: 1) Set tcpdumps to private. 2) Patch containing fix has been sent upstream http://thread.gmane.org/gmane.linux.kernel.cifs/10392
(In reply to Sachin Prabhu from comment #12) > Update: > > 1) Set tcpdumps to private. > > 2) Patch containing fix has been sent upstream > http://thread.gmane.org/gmane.linux.kernel.cifs/10392 We can carry this in Fedora until it works its way into upstream. Is there a reason you didn't include it as a stable submission?
Waiting for upstream to accept the patch. The patch sent upstream has been slightly modified.
+1 for having it in the Fedora kernel until it's upstream :)
Fixed in Fedora git.
kernel-3.17.8-300.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kernel-3.17.8-300.fc21
kernel-3.17.8-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.17.8-200.fc20
Package kernel-3.17.8-200.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.17.8-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0515/kernel-3.17.8-200.fc20 then log in and leave karma (feedback).
kernel-3.17.8-300.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.17.8-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
3.17.8-200.fc20 has fixed the problem for me. Thank you.