Description of problem: Seems like automount is passing -s to ntfs-3g which is not a recognized option and makes the mount fails. This used to work with FC20. Version-Release number of selected component (if applicable): autofs-5.1.0-8.fc21.x86_64 ntfs-3g-2014.2.15-4.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. add to /etc/auto.master /misc /etc/auto.misc 2. add/create /etc/auto.misc with windows -fstype=auto,nocase,user,uid=1000,gid=1000 :/dev/sda2 where /dev/sda2 is an NTFS disk 3. add "-v -d" to OPTIONS in /etc/sysconfig/automount 4. start/restart autofs Actual results: Mount fails, in /var/log/messages (or systemd's journals) one sees the mount command as mount -t auto -s -o nocase,user,uid=1000,gid=1000 /dev/sda2 /misc/windows followed a few lines down by the error message ntfs-3g: Unknown option '-s'. Expected results: Successful mount as in F20 Additional info:
(In reply to Henrique Martins from comment #0) > Description of problem: > Seems like automount is passing -s to ntfs-3g which is not a recognized > option and makes the mount fails. This used to work with FC20. This is possibly logged against the wrong component. The -s flag is meant to be handled by mount(8) I believe. automount(8) has always added the option so that maps that may be used with other operation systems that have different options requirements will still work within Linux. It is supposed to tell mount(8) to not fail on invalid options. It's not new and hasn't been added recently.
(In reply to Henrique Martins from comment #0) > Description of problem: > Seems like automount is passing -s to ntfs-3g which is not a recognized > option and makes the mount fails. This used to work with FC20. > > > Version-Release number of selected component (if applicable): > autofs-5.1.0-8.fc21.x86_64 > ntfs-3g-2014.2.15-4.fc21.x86_64 > > How reproducible: > Always > > Steps to Reproduce: > 1. add to /etc/auto.master > /misc /etc/auto.misc > 2. add/create /etc/auto.misc with > windows -fstype=auto,nocase,user,uid=1000,gid=1000 :/dev/sda2 > where /dev/sda2 is an NTFS disk AFAIK fstype=auto has never been a valid option for autofs although it shouldn't make autofs choke. I think it just causes the generic mount module to be called to perform the mount and so pass "-t auto" to mount(8) telling it to attempt to guess file system type. I'll need to have a look to check that is what it does ..... nevertheless the -s option shouldn't passed on by mount(8). Ian
(In reply to Ian Kent from comment #1) > This is possibly logged against the wrong component. I wasn't sure whether to file with autofs or ntfs-3g (or even mount) Feel free to re-assign. > The -s flag is meant to be handled by mount(8) I believe. man mount claims it is only supported by mount.nfs. > automount(8) has always added the option It is probably then that ntfs-3g now rejects it, and thus the bug should be moved there.
(In reply to Ian Kent from comment #2) > AFAIK fstype=auto has never been a valid option for autofs although > it shouldn't make autofs choke. I've had my maps like that for a long time, with lots of FC versions. I think I switched to auto to be able to automount CD-ROMs with different file systems on them, be it iso9660/cdfs or iso13346/udf.
(In reply to Ian Kent from comment #1) > (In reply to Henrique Martins from comment #0) > > Description of problem: > > Seems like automount is passing -s to ntfs-3g which is not a recognized > > option and makes the mount fails. This used to work with FC20. > > This is possibly logged against the wrong component. > > The -s flag is meant to be handled by mount(8) I believe. > > automount(8) has always added the option so that maps that may > be used with other operation systems that have different options > requirements will still work within Linux. It is supposed to tell > mount(8) to not fail on invalid options. > > It's not new and hasn't been added recently. The sloppy option has been added to mounts (at least in the generic and nfs autofs mount modules) since before 2006. I see that in F20 mount(8) special cases the sloppy option and only passes it on to nfs mounts. There's this comment in the source: * TODO: remove the exception for "nfs", -s is documented * for years and should be usable everywhere. and it appears to have been done now. Given that mount(8) had a special case for this for nfs mounts the sloppy option wasn't being passed on previously so I could reasonably safely remove the addition of the option for all the generic mount module and check if any other file system types with custom mount modules support the sloppy option. That's going to take a while though as I have several other fairly high priority things to do. Ian
(In reply to Ian Kent from comment #5) > There's this comment in the source: > * TODO: remove the exception for "nfs", -s is documented > * for years and should be usable everywhere. > and it appears to have been done now. Not sure about you changing anything then. Doesn't the "should be usable everywhere" point to mount.ntfs-3g now needing to accept bad options, including -s, and ignore them? I think we should move this to ntfs-3g ...
(In reply to Henrique Martins from comment #6) > (In reply to Ian Kent from comment #5) > > > There's this comment in the source: > > * TODO: remove the exception for "nfs", -s is documented > > * for years and should be usable everywhere. > > and it appears to have been done now. > > Not sure about you changing anything then. Doesn't the "should be usable > everywhere" point to mount.ntfs-3g now needing to accept bad options, > including -s, and ignore them? I think we should move this to ntfs-3g ... I think your right. I had a look at mount.cifs(8) and it doesn't mention it on its man page but the -s option is handled in the source. Don't know if it actually does what's expected but it's reasonable to expect so. It also appears that a number of other file systems are handled within libmount now which just means the sloppy option would be handled by mount(8).
Reassigning to ntfs-3g.
Created attachment 979495 [details] Ignoring option -s Please try this patch, which only leads to ignoring option -s
(In reply to Jean-Pierre André from comment #9) > Created attachment 979495 [details] > Ignoring option -s > > Please try this patch, which only leads to ignoring option -s That should work. There may not be any need to worry about ignoring invalid options as it might not be needed for use with other OS platforms, not sure.
(In reply to Jean-Pierre André from comment #9) > Please try this patch, which only leads to ignoring option -s That (obviously:)) works. Just tried it and installed on the affected system.
(In reply to Ian Kent from comment #10) > There may not be any need to worry about ignoring invalid options > as it might not be needed for use with other OS platforms, not sure. On FC21, and before, automount passes -s to mount as per comment #1. Not sure if due to the use of fstype=auto or not. Starting with FC21, per comment #5, mount passes -s to all helpers. Thus, if ntfs-3g is to fail on an unknown -s, either automount, or more likely mount, ought not pass it. If that is the case we should move this to mount or get whoever decided to pass -s to all helpers rethink the situation. Not sure if that is done here in bugzilla or some FC mailing list.
ntfs-3g-2014.2.15-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/ntfs-3g-2014.2.15-7.fc21
(In reply to Henrique Martins from comment #12) > (In reply to Ian Kent from comment #10) > > > There may not be any need to worry about ignoring invalid options > > as it might not be needed for use with other OS platforms, not sure. > > On FC21, and before, automount passes -s to mount as per comment #1. Not > sure if due to the use of fstype=auto or not. autofs has always passed the sloppy option to mount(8) for all file systems but, until f21, mount(8) would not pass the sloppy option on to file systems other than nfs. > > Starting with FC21, per comment #5, mount passes -s to all helpers. Yes. > > Thus, if ntfs-3g is to fail on an unknown -s, either automount, or more > likely mount, ought not pass it. If that is the case we should move this to > mount or get whoever decided to pass -s to all helpers rethink the > situation. Not sure if that is done here in bugzilla or some FC mailing > list. So mount.ntfs-3g ignoring the sloppy option essentially restores the previous behaviour. Certainly it doesn't handle not failing on invalid options, and that may be something to go on the todo list for ntfs-3g, but it wasn't done before either. There are few external mount helpers now so the sloppy option is handled by mount(8) internally for most file systems, at least the most frequently used ones. So the change here is probably sufficient for the moment. If we get further problem reports (for ntfs-3g or other file systems) it would be worth re-thinking what we should do.
Package ntfs-3g-2014.2.15-7.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 ntfs-3g-2014.2.15-7.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0613/ntfs-3g-2014.2.15-7.fc21 then log in and leave karma (feedback).
> autofs has always passed the sloppy option to mount(8) for all file > systems but, until f21, mount(8) would not pass the sloppy option > on to file systems other than nfs. On fc21 the mount manual says "Not all filesystems support this option. Currently it's supported by the mount.nfs mount helper only." > Certainly it doesn't handle not failing > on invalid options, and that may be something to go on the todo > list for ntfs-3g, but it wasn't done before either. Are these sloppy options documented somewhere, and are we talking of the options announced by "-o" ? Are these sloppy options meaningful for all file systems, or only for remote file systems (like nts or cifs) which may run on a different operating system ? Currently if ntfs-3g gets an unknown "-o" option, it assumes it is a fuse option, and if it happens to be unknown to fuse, mounting is rejected by fuse. Of course, it is up to fuse to accept new options (I have just read a proposal to add an option "affinity=..." to improve scalability). If both autofs and fuse have an open list of possible options, ntfs-3g (and all file systems relying on fuse) can only wait for new sloppy options to emerge and submit a patch to discard them.
(In reply to Jean-Pierre André from comment #16) > > autofs has always passed the sloppy option to mount(8) for all file > > systems but, until f21, mount(8) would not pass the sloppy option > > on to file systems other than nfs. > > On fc21 the mount manual says "Not all filesystems support this option. > Currently it's supported by the mount.nfs mount helper only." That's clearly out of date. Maybe we will need to raise a bug against util-linux later to address that. > > > Certainly it doesn't handle not failing > > on invalid options, and that may be something to go on the todo > > list for ntfs-3g, but it wasn't done before either. > > Are these sloppy options documented somewhere, and are we talking of the > options announced by "-o" ? Are these sloppy options meaningful for all file > systems, or only for remote file systems (like nts or cifs) which may run on > a different operating system ? I don't think you understood my previous explanation. All "the" sloppy option (-s) says is "don't fail on any option you get that's invalid, ignore it", nothing more. There is no implication of selective ignoring of options and there can't be because such options would typically be used in implementations of the given file system on other operating systems. As I've said before it is meant to allow options that may be needed on other operating systems to be included in autofs mount map entries (that are used with other sun map format autofs implementations on other operating systems) without them causing mount failures when used on Linux systems. This was a significant problem with NFS years ago but is mostly not a problem any more since mount.nfs(8) has been updated to accept most variants of options. > > Currently if ntfs-3g gets an unknown "-o" option, it assumes it is a fuse > option, and if it happens to be unknown to fuse, mounting is rejected by > fuse. Of course, it is up to fuse to accept new options (I have just read a > proposal to add an option "affinity=..." to improve scalability). > > If both autofs and fuse have an open list of possible options, ntfs-3g (and > all file systems relying on fuse) can only wait for new sloppy options to > emerge and submit a patch to discard them. autofs obviously has a list of options it supports but they should not and don't make it to mounts themselves, they are consumed by autofs, of course.
> All "the" sloppy option (-s) says is "don't fail on any option > you get that's invalid, ignore it", nothing more. So let me take an example : mount -t ntfs-3g -s -o option-for-solaris /dev/sda2 /windows ntfs-3g will not fail on this, though the option -o contains an invalid option. The option-for-solaris will just be passed on to fuse, and fuse will decide what to do about it, including refusing to mount.
(In reply to Jean-Pierre André from comment #18) > > All "the" sloppy option (-s) says is "don't fail on any option > > you get that's invalid, ignore it", nothing more. > > So let me take an example : > mount -t ntfs-3g -s -o option-for-solaris /dev/sda2 /windows > > ntfs-3g will not fail on this, though the option -o contains an invalid > option. The option-for-solaris will just be passed on to fuse, and fuse will > decide what to do about it, including refusing to mount. Ok, I get it, I think that's a question for the ntfs-3g mintainers. Nevertheless, the change here does restore the previous behaviour for the time being.
ntfs-3g-2014.2.15-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.