Cloning the bug for the autofs changes that still need to be done.

+++ This bug was initially created as a clone of Bug #825836 +++

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.

--- Additional comment from m.a.young.uk on 2012-05-29 11:37:30 EDT ---

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.

--- Additional comment from ikent on 2012-05-29 20:30:20 EDT ---

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.

--- Additional comment from ikent on 2012-05-29 20:33:16 EDT ---

(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.

--- Additional comment from ikent on 2012-05-29 20:40:34 EDT ---

(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.

--- Additional comment from ikent on 2012-05-29 21:50:06 EDT ---

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.

--- Additional comment from m.a.young.uk on 2012-05-30 05:13:37 EDT ---

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.

--- Additional comment from m.a.young.uk on 2012-05-30 05:31:53 EDT ---

(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.

--- Additional comment from ikent on 2012-05-30 08:18:11 EDT ---

(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

--- Additional comment from gedetil.ca on 2012-06-06 12:27:20 EDT ---

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.

--- Additional comment from ikent on 2012-06-06 21:33:21 EDT ---

(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.

--- Additional comment from paulds on 2012-06-13 11:44:37 EDT ---

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.

--- Additional comment from ikent on 2012-06-14 06:13:40 EDT ---

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?

--- Additional comment from kzak on 2012-06-14 07:50:40 EDT ---

(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.

--- Additional comment from updates on 2012-06-19 06:35:33 EDT ---

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

--- Additional comment from updates on 2012-06-19 20:30:40 EDT ---

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).

--- Additional comment from paulds on 2012-06-20 17:18:47 EDT ---

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.

--- Additional comment from ikent on 2012-06-20 23:14:13 EDT ---

(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.

--- Additional comment from m.a.young.uk on 2012-06-21 14:02:08 EDT ---

mount -s works as an ordinary user on a system with the new util-linux but not on another one that doesn't.

--- Additional comment from paulds on 2012-06-21 16:53:45 EDT ---

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.

--- Additional comment from updates on 2012-06-27 23:30:09 EDT ---

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.