Bug 1180663 - automount passing -s to ntfs-3g which fails
Summary: automount passing -s to ntfs-3g which fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ntfs-3g
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-09 16:16 UTC by Henrique Martins
Modified: 2015-01-21 23:05 UTC (History)
3 users (show)

Fixed In Version: ntfs-3g-2014.2.15-7.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 23:05:25 UTC
Type: Bug


Attachments (Terms of Use)
Ignoring option -s (632 bytes, patch)
2015-01-13 07:22 UTC, Jean-Pierre André
no flags Details | Diff

Description Henrique Martins 2015-01-09 16:16:33 UTC
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:

Comment 1 Ian Kent 2015-01-10 04:04:39 UTC
(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.

Comment 2 Ian Kent 2015-01-10 04:14:27 UTC
(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

Comment 3 Henrique Martins 2015-01-10 15:29:46 UTC
(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.

Comment 4 Henrique Martins 2015-01-10 15:33:54 UTC
(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.

Comment 5 Ian Kent 2015-01-12 02:34:26 UTC
(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

Comment 6 Henrique Martins 2015-01-12 18:47:20 UTC
(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 ...

Comment 7 Ian Kent 2015-01-13 02:05:01 UTC
(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).

Comment 8 Ian Kent 2015-01-13 02:06:54 UTC
Reassigning to ntfs-3g.

Comment 9 Jean-Pierre André 2015-01-13 07:22:43 UTC
Created attachment 979495 [details]
Ignoring option -s

Please try this patch, which only leads to ignoring option -s

Comment 10 Ian Kent 2015-01-13 08:07:16 UTC
(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.

Comment 11 Henrique Martins 2015-01-13 15:26:51 UTC
(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.

Comment 12 Henrique Martins 2015-01-13 15:32:46 UTC
(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.

Comment 13 Fedora Update System 2015-01-13 20:07:42 UTC
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

Comment 14 Ian Kent 2015-01-14 01:59:47 UTC
(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.

Comment 15 Fedora Update System 2015-01-14 07:27:51 UTC
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).

Comment 16 Jean-Pierre André 2015-01-14 07:57:23 UTC
> 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.

Comment 17 Ian Kent 2015-01-14 10:13:29 UTC
(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.

Comment 18 Jean-Pierre André 2015-01-14 11:58:15 UTC
> 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.

Comment 19 Ian Kent 2015-01-15 00:44:19 UTC
(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.

Comment 20 Fedora Update System 2015-01-21 23:05:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.