Description of problem: I've just upgraded from kernel 3.13.11 to 3.14.17 and immediately found that NFS V3 mounted file systems don't work properly anymore. Creating files often return EINVAL. NFS V4 seems ok though. Version-Release number of selected component (if applicable): kernel-PAE-3.14.17-100.fc19.i686 kernel-3.14.17-100.fc19.x86_64 How reproducible: very, esp soon after reboot Steps to Reproduce: 1. cd /nfsv3mount 2. cp /etc/group g 3. Actual results: cp: cannot create regular file 'g': Invalid argument Expected results: no error Additional info: $ df . Filesystem 1K-blocks Used Available Use% Mounted on maxim:/app/01/home/iand 188340224K 156058624K 30398464K 84% /home/iand $ mount |grep iand maxim:/app/01/home/iand on /home/iand type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.41.22,mountvers=3,mountport=57921,mountproto=udp,local_lock=none,addr=192.168.41.22) Googling around shows this: https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.14.11 which has a few mentions of NFS related cache tweaks; I'd use that as a starting point for investigation... Rolling back to the prior 3.13.11 kernel restores sanity.
What type of server is it and is there any error messages in /var/log/messages? If not please turn on NFS debugging with : rpcdebug -m nfs -s all
The servers are Solaris 9 and Solaris 10. tcpdump of the NFS stream shows that just after the create is issued, a SETACL is being issued, and that is returning EINVAL. I've found that mounting the file system with "noacl" avoids the issue, but clearly the default has changed between these two kernels.
Created attachment 930219 [details] Fix another acl regression Does the following patch fix the regression?
I'm seeing similar problem with creating a directory: # mount -t nfs -o nfsvers=3,tcp sol10-nfs:/export/home /mnt/sol10-nfs # mkdir /mnt/sol10-nfs/`hostname` mkdir: cannot create directory ‘/mnt/sol10-nfs/dell-pem520-03’: Invalid argument # rmdir /mnt/sol10-nfs/`hostname` I bisected it down to: commit 013cdf1088d7235da9477a2375654921d9b9ba9f Author: Christoph Hellwig <hch> Date: Fri Dec 20 05:16:53 2013 -0800 nfs: use generic posix ACL infrastructure for v3 Posix ACLs With patch from comment 4 (applied on top of 013cdf1088d7235da9477a2375654921d9b9ba9f) I no longer see this problem: # mkdir /mnt/sol10-nfs/`hostname` # cp /boot/vmlinuz-3.13.0+ /mnt/sol10-nfs/`hostname`/ # rm -rf /mnt/sol10-nfs/`hostname` # umount /mnt/sol10-nfs
(In reply to Trond Myklebust from comment #4) > Created attachment 930219 [details] > Fix another acl regression > > Does the following patch fix the regression? Yes it does... Trond would like me to post it to the list with a Tested-by: line? Jan, Here is a scratch build with the patch applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=7469047 See the patch also help your failure...
The patch has been pushed into the linux-nfs.org git tree with a Cc: stable line. It will go out to Linus in the next few days.
(In reply to Steve Dickson from comment #6) > Jan, Here is a scratch build with the patch applied: > http://koji.fedoraproject.org/koji/taskinfo?taskID=7469047 > > See the patch also help your failure... Steve, it does help: # uname -r 3.16.1-301.bz1132786.fc21.x86_64 # mount -t nfs -o nfsvers=3,tcp sol10-nfs:/export/home /mnt/sol10-nfs # mkdir /mnt/sol10-nfs/`hostname` # rmdir /mnt/sol10-nfs/`hostname` # umount /mnt/sol10-nfs Connectathon against sol10 passed as well: ***** Summary for server 'sol10-nfs': '0' tests failed ***** NFS version Type Test Return code nfsvers=3 tcp -b:base 0 nfsvers=3 tcp -g:general 0 nfsvers=3 tcp -s:special 0 nfsvers=3 tcp -l:lock 0 nfsvers=4 tcp -b:base 0 nfsvers=4 tcp -g:general 0 nfsvers=4 tcp -s:special 0 nfsvers=4 tcp -l:lock 0
*** Bug 1131212 has been marked as a duplicate of this bug. ***
I've added the patch to all Fedora branches. Thanks everyone!
*** Bug 1138446 has been marked as a duplicate of this bug. ***
kernel-3.16.2-300.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kernel-3.16.2-300.fc21
Package kernel-3.16.2-300.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.16.2-300.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10312/kernel-3.16.2-300.fc21 then log in and leave karma (feedback).
kernel-3.16.2-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.16.2-200.fc20
Will there be an fc19 kernel released with this fix?
Yes.
kernel-3.14.18-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.18-100.fc19
kernel-3.16.2-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.14.19-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.19-100.fc19
kernel-3.16.2-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.14.19-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.