I have updated a system from Fedora 16 to Fedora 17 and discovered that the automounts have stopped working. The problem seems to be that mount.nfs has stopped supporting the quota/noquota option and returns an error. If it was a static mount I could clearly fix it, but the automount map comes through NIS and I can't edit it without breaking other, more important, systems. I believe automount already removes some options from the maps before issuing the mount command, so would it possible to add quota and noquota to the options that are stripped for compatibility.
While this might still be a feature worth considering, I worked around the automount problems I was having with a mixture of manual configuration and program (shell script) maps.
Give me some more information. What do your maps look like and try and describe what you are trying to workaround? How about posting a debug log that shows the error messages your getting so I can relate that back to mount(8) or mount.nfs(8) so I can try and find what changed.
(In reply to comment #1) > While this might still be a feature worth considering, I worked around the > automount problems I was having with a mixture of manual configuration and > program (shell script) maps. We've been here before long ago. Adding special case handling to automount will be a problem because it will always need maintenance and older binaries won't just work when improvements are made. Ideally we would be able to work around this in some other way.
(In reply to comment #0) > I have updated a system from Fedora 16 to Fedora 17 and discovered that the > automounts have stopped working. > The problem seems to be that mount.nfs has stopped supporting the > quota/noquota option and returns an error. If it was a static mount I could > clearly fix it, but the automount map comes through NIS and I can't edit it > without breaking other, more important, systems. I believe automount already > removes some options from the maps before issuing the mount command, so > would it possible to add quota and noquota to the options that are stripped > for compatibility. automount only ignores the bg and nofg mount options. If it isn't posible to edit the NIS maps you can override them is various wats that may or may not help.
AFAICT from the nfs-utils and current kernel source using options that aren't known should not cause mounts to fail. automount calls mount(8) with the sloppy option (-s) which should cause unknown options to be ignored. There may be special cases that aren't obvious but I can't tell without more information.
I think the sloppy option isn't being passed. Here are some debug log entries from some testing I did May 28 16:31:48 myserver automount[11040]: mount_mount: mount(nfs): calling mkdir_path /usr/local/sbin May 28 16:31:48 myserver automount[11040]: mount_mount: mount(nfs): calling mount -t nfs -o sec=krb5,nosuid,rw,intr,noquota,timeo=44,retrans=10 nfshost:/path/to/usr/local/sbin /usr/local/sbin May 28 16:31:48 myserver automount[11040]: spawn_mount: mtab link detected, passing -n to mount May 28 16:31:48 myserver automount[11040]: >> mount.nfs: an incorrect mount option was specified May 28 16:31:48 myserver automount[11040]: mount(nfs): nfs: mount failure nfshost:/path/to/usr/local/sbin on /usr/local/sbin My workaround was basically to copy the auto.master NIS map into a /etc/auto.master.d file and delete any quota or noquota options, and use scripts like #!/bin/bash ypmatch $1 auto.usr.local | sed -e "s/,noquota//" | sed -e "s/,quota//" to do the same for each of the other automount maps.
(In reply to comment #6) > May 28 16:31:48 myserver automount[11040]: mount_mount: mount(nfs): calling > mount -t nfs -o sec=krb5,nosuid,rw,intr,noquota,timeo=44,retrans=10 > nfshost:/path/to/usr/local/sbin /usr/local/sbin > May 28 16:31:48 myserver automount[11040]: spawn_mount: mtab link detected, > passing -n to mount > May 28 16:31:48 myserver automount[11040]: >> mount.nfs: an incorrect mount > option was specified If I do a manual mount of the share with the same options, it fails with the error mount.nfs: an incorrect mount option was specified It does mount if I add the -s option.
(In reply to comment #6) > I think the sloppy option isn't being passed. Here are some debug log > entries from some testing I did > > May 28 16:31:48 myserver automount[11040]: mount_mount: mount(nfs): calling > mkdir_path /usr/local/sbin > May 28 16:31:48 myserver automount[11040]: mount_mount: mount(nfs): calling > mount -t nfs -o sec=krb5,nosuid,rw,intr,noquota,timeo=44,retrans=10 > nfshost:/path/to/usr/local/sbin /usr/local/sbin > May 28 16:31:48 myserver automount[11040]: spawn_mount: mtab link detected, > passing -n to mount > May 28 16:31:48 myserver automount[11040]: >> mount.nfs: an incorrect mount > option was specified > May 28 16:31:48 myserver automount[11040]: mount(nfs): nfs: mount failure > nfshost:/path/to/usr/local/sbin on /usr/local/sbin Right, that's not the way it's supposed to be. I'll look a bit further and see if I can spot what's wrong. > > My workaround was basically to copy the auto.master NIS map into a > /etc/auto.master.d file and delete any quota or noquota options, and use > scripts like > > #!/bin/bash > ypmatch $1 auto.usr.local | sed -e "s/,noquota//" | sed -e "s/,quota//" > > to do the same for each of the other automount maps. Yeah, the individual map entry options will be used, there's not much else you can do about that. Ian
I'm hoping for a fix to this soon. Almost all of my systems rely on NIS automount maps, which I can't change without breaking Solaris clients, so I really need the quota/noquota options in the maps. I have one broken test system that I upgraded to F17, and others that are now on "hold" for upgrading. I think the last time this was broken, it was a problem with the "mount" command itself. This time, it seems to be "automount" that's doing the wrong thing.
(In reply to comment #9) > I'm hoping for a fix to this soon. Almost all of my systems rely on NIS > automount maps, which I can't change without breaking Solaris clients, so I > really need the quota/noquota options in the maps. > > I have one broken test system that I upgraded to F17, and others that are > now on "hold" for upgrading. OK, I'll have another look today. > > I think the last time this was broken, it was a problem with the "mount" > command itself. This time, it seems to be "automount" that's doing the > wrong thing. Right, most likey when it tried to drop support for the sloppy option.
We just ran into this problem as well, and I was about to file a bug when I saw this one. It appears that some patch to autofs between F16 and F17 changed its default behavior, and autofs no longer passes the "sloppy" option to mount by default. Note that until this is fixed, you can easily work around this bug and return autofs to its previous behavior by setting OPTIONS="-O sloppy" in /etc/sysconfig/autofs.
Created attachment 591800 [details] Patch - allow sloppy for non-root Don't know how you want to handle this Karel since I see there has been some work relating to the sloppy option with mount(8) recently. I think the patch explains fairly clearly what the problem in this bug is. Comments please?
(In reply to comment #12) > Created attachment 591800 [details] > Patch - allow sloppy for non-root > > Don't know how you want to handle this Karel since I see there > has been some work relating to the sloppy option with mount(8) > recently. > > I think the patch explains fairly clearly what the problem in > this bug is. Thanks for the patch! I'll apply the patch ASAP.
util-linux-2.21.2-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/util-linux-2.21.2-2.fc17
Package util-linux-2.21.2-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing util-linux-2.21.2-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9673/util-linux-2.21.2-2.fc17 then log in and leave karma (feedback).
As I noted in bodhi just now, this update failed to correct the problem with automount on our systems. We removed the "-O sloppy" option, installed this update, restarted autofs, and immediately all of our automount maps containing the "quota" option began failing again. We added "-O sloppy" back to /etc/sysconfig/autofs and the problem went away again.
(In reply to comment #17) > As I noted in bodhi just now, this update failed to correct the problem with > automount on our systems. We removed the "-O sloppy" option, installed this > update, restarted autofs, and immediately all of our automount maps > containing the "quota" option began failing again. We added "-O sloppy" > back to /etc/sysconfig/autofs and the problem went away again. The reason for that is apparent if you read the description of the patch in comment #12. To verify the util-linux correction typing the command "mount -s" as a non-root user needs to not return an error. Once this bug is verified I'll either clone this bug or open a new bug and rebuild autofs, and that will resolve the issue.
mount -s works as an ordinary user on a system with the new util-linux but not on another one that doesn't.
My apologies; I guess I didn't read carefully the first time. Sorry about that. Yes, I can confirm that the util-linux update does restore non-root users' ability to run "mount -s" without error. Will update my bodhi report accordingly.
util-linux-2.21.2-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.