mount: sshfs problem with "defaults" option after 2.39 upgrade

mount: sshfs problem with "defaults" option after 2.39 upgrade

[Quentin Rameau]

Hi,

I just updated util-linux to 2.39 from 2.38.1 (on Alpine Linux),
and new mount triggers an error for an old sshfs fstab mount entry,
that was working until now.

The line in question is:

user@host:path /media/ssh/path sshfs defaults,nosuid,nodev,noexec,noatime,noauto,_netdev,user,idmap=user,allow_other,rec 0 0

and fails with:

$ mount /media/ssh/path
fuse: unknown option(s): `-o defaults'

I can see in the trace that "defaults" is actually passed to the helper

30906 execve("/sbin/mount.sshfs", ["/sbin/mount.sshfs", "user@host:path", "/media/ssh/path", "-o", "rw,defaults,noatime,_netdev,...", <truncated here>

And running it with LIBMOUNT_DEBUG=all shows

30933: libmount:   UPDATE: 30933: libmount:       FS: synced: vfs: 'rw,noatime,nodev,nosuid,noexec' fs: 'idmap=user,allow_other,reconnect' user: 'defaults,noauto,_netdev,, optstr: 'rw,defaults,noatime,noauto,_netdev,user=quinq,nodev,nosuid,noexec,allow_other,reconnect'
[...]
optstr: rw,defaults,noatime,noauto,_netdev,nodev,nosuid,noexec,idmap=user,allow_other,reconnect
VFS-optstr: rw,noatime,nodev,nosuid,noexec
FS-opstr: idmap=user,allow_other,reconnect
user-optstr: defaults,noauto,_netdev

The "defaults" option is stripped from the analog traces with mount 2.38.1

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Thomas Weißschuh]

Hi Quentin,

On 2023-05-21 18:18:14+0200, Quentin Rameau wrote:
> Hi,
> 
> I just updated util-linux to 2.39 from 2.38.1 (on Alpine Linux),
> and new mount triggers an error for an old sshfs fstab mount entry,
> that was working until now.
> 
> The line in question is:
> 
> user@host:path /media/ssh/path sshfs defaults,nosuid,nodev,noexec,noatime,noauto,_netdev,user,idmap=user,allow_other,rec 0 0
> 
> and fails with:
> 
> $ mount /media/ssh/path
> fuse: unknown option(s): `-o defaults'
> 
> I can see in the trace that "defaults" is actually passed to the helper
> 
> 30906 execve("/sbin/mount.sshfs", ["/sbin/mount.sshfs", "user@host:path", "/media/ssh/path", "-o", "rw,defaults,noatime,_netdev,...", <truncated here>
> 
> And running it with LIBMOUNT_DEBUG=all shows
> 
> 30933: libmount:   UPDATE: 30933: libmount:       FS: synced: vfs: 'rw,noatime,nodev,nosuid,noexec' fs: 'idmap=user,allow_other,reconnect' user: 'defaults,noauto,_netdev,, optstr: 'rw,defaults,noatime,noauto,_netdev,user=quinq,nodev,nosuid,noexec,allow_other,reconnect'
> [...]
> optstr: rw,defaults,noatime,noauto,_netdev,nodev,nosuid,noexec,idmap=user,allow_other,reconnect
> VFS-optstr: rw,noatime,nodev,nosuid,noexec
> FS-opstr: idmap=user,allow_other,reconnect
> user-optstr: defaults,noauto,_netdev
> 
> The "defaults" option is stripped from the analog traces with mount 2.38.1

Could you try https://github.com/util-linux/util-linux/pull/2250 ?


Thomas

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Quentin Rameau]

> Hi Quentin,

Hi Thomas,

> > I just updated util-linux to 2.39 from 2.38.1 (on Alpine Linux),
> > and new mount triggers an error for an old sshfs fstab mount entry,
> > that was working until now.
> > 
> > The line in question is:
> > 
> > user@host:path /media/ssh/path sshfs defaults,nosuid,nodev,noexec,noatime,noauto,_netdev,user,idmap=user,allow_other,rec 0 0
> > 
> > and fails with:
> > 
> > $ mount /media/ssh/path
> > fuse: unknown option(s): `-o defaults'
> 
> Could you try https://github.com/util-linux/util-linux/pull/2250 ?

This makes that problem go away indeed, thank you!

On a side-note, should that flag be applied to other generic parameters
too, like user(s) for example?

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Thomas Weißschuh]

On 2023-05-21 20:15:34+0200, Quentin Rameau wrote:
> > Hi Quentin,
> 
> Hi Thomas,
> 
> > > I just updated util-linux to 2.39 from 2.38.1 (on Alpine Linux),
> > > and new mount triggers an error for an old sshfs fstab mount entry,
> > > that was working until now.
> > > 
> > > The line in question is:
> > > 
> > > user@host:path /media/ssh/path sshfs defaults,nosuid,nodev,noexec,noatime,noauto,_netdev,user,idmap=user,allow_other,rec 0 0
> > > 
> > > and fails with:
> > > 
> > > $ mount /media/ssh/path
> > > fuse: unknown option(s): `-o defaults'
> > 
> > Could you try https://github.com/util-linux/util-linux/pull/2250 ?
> 
> This makes that problem go away indeed, thank you!

Great, you're welcome!

> On a side-note, should that flag be applied to other generic parameters
> too, like user(s) for example?

I guess they are useful for the helpers.

If the helpers were able to handle it before it should be fine.
(They were passed in 2.38)

One could even argue that "defaults" should have been fine to be passed,
but now it's a regression so needs to be fixed.

Thomas

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Quentin Rameau]

> > On a side-note, should that flag be applied to other generic parameters
> > too, like user(s) for example?  
> 
> I guess they are useful for the helpers.
> 
> If the helpers were able to handle it before it should be fine.
> (They were passed in 2.38)
> 
> One could even argue that "defaults" should have been fine to be passed,
> but now it's a regression so needs to be fixed.

One difference that I can see is that before, "user" was being passed
but now, "user=$user" is being passed (and that gives an error too)

With mount patched with the above patch, and "user" option in the fstab

$ mount /mnt/ssh/path
fusermount3: unknown option 'user=quinq

But maybe that should be a different thread, what do you think?

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Thomas Weißschuh]

On 2023-05-21 21:20:18+0200, Quentin Rameau wrote:
> > > On a side-note, should that flag be applied to other generic parameters
> > > too, like user(s) for example?  
> > 
> > I guess they are useful for the helpers.
> > 
> > If the helpers were able to handle it before it should be fine.
> > (They were passed in 2.38)
> > 
> > One could even argue that "defaults" should have been fine to be passed,
> > but now it's a regression so needs to be fixed.
> 
> One difference that I can see is that before, "user" was being passed
> but now, "user=$user" is being passed (and that gives an error too)
> 
> With mount patched with the above patch, and "user" option in the fstab
> 
> $ mount /mnt/ssh/path
> fusermount3: unknown option 'user=quinq
> 
> But maybe that should be a different thread, what do you think?

I can't reproduce this.

Could you provide more traces?

Or maybe try to adapt tests/ts/mount/special in the util-linux source to
test for it. That would make it easier to reproduce and fix.

Thomas

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Karel Zak]

On Sun, May 21, 2023 at 09:20:18PM +0200, Quentin Rameau wrote:
> > One could even argue that "defaults" should have been fine to be passed,
> > but now it's a regression so needs to be fixed.
> 
> One difference that I can see is that before, "user" was being passed
> but now, "user=$user" is being passed (and that gives an error too)
> 
> With mount patched with the above patch, and "user" option in the fstab
> 
> $ mount /mnt/ssh/path
> fusermount3: unknown option 'user=quinq
> 
> But maybe that should be a different thread, what do you think?

I'll fix it. You're right.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Karel Zak]

On Mon, May 22, 2023 at 04:21:54PM +0200, Karel Zak wrote:
> On Sun, May 21, 2023 at 09:20:18PM +0200, Quentin Rameau wrote:
> > > One could even argue that "defaults" should have been fine to be passed,
> > > but now it's a regression so needs to be fixed.
> > 
> > One difference that I can see is that before, "user" was being passed
> > but now, "user=$user" is being passed (and that gives an error too)
> > 
> > With mount patched with the above patch, and "user" option in the fstab
> > 
> > $ mount /mnt/ssh/path
> > fusermount3: unknown option 'user=quinq
> > 
> > But maybe that should be a different thread, what do you think?
> 
> I'll fix it. You're right.

You need https://github.com/util-linux/util-linux/commit/fe0b1e793c9017edba72768e2e0b4c769c204604

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Quentin Rameau]

Hi Karel,

> On Mon, May 22, 2023 at 04:21:54PM +0200, Karel Zak wrote:
> > On Sun, May 21, 2023 at 09:20:18PM +0200, Quentin Rameau wrote:
> > > > One could even argue that "defaults" should have been fine to be passed,
> > > > but now it's a regression so needs to be fixed.
> > > 
> > > One difference that I can see is that before, "user" was being passed
> > > but now, "user=$user" is being passed (and that gives an error too)
> > > 
> > > With mount patched with the above patch, and "user" option in the fstab
> > > 
> > > $ mount /mnt/ssh/path
> > > fusermount3: unknown option 'user=quinq
> > > 
> > > But maybe that should be a different thread, what do you think?
> > 
> > I'll fix it. You're right.
> 
> You need https://github.com/util-linux/util-linux/commit/fe0b1e793c9017edba72768e2e0b4c769c204604

I can confirm that this fixes that second problem indeed, thanks!

Re: mount: sshfs problem with "defaults" option after 2.39 upgrade

[Quentin Rameau]

Hello Thomas,

> > > > On a side-note, should that flag be applied to other generic parameters
> > > > too, like user(s) for example?    
> > > 
> > > I guess they are useful for the helpers.
> > > 
> > > If the helpers were able to handle it before it should be fine.
> > > (They were passed in 2.38)
> > > 
> > > One could even argue that "defaults" should have been fine to be passed,
> > > but now it's a regression so needs to be fixed.  
> > 
> > One difference that I can see is that before, "user" was being passed
> > but now, "user=$user" is being passed (and that gives an error too)
> > 
> > With mount patched with the above patch, and "user" option in the fstab
> > 
> > $ mount /mnt/ssh/path
> > fusermount3: unknown option 'user=quinq
> > 
> > But maybe that should be a different thread, what do you think?  
> 
> I can't reproduce this.
> 
> Could you provide more traces?
> 
> Or maybe try to adapt tests/ts/mount/special in the util-linux source to
> test for it. That would make it easier to reproduce and fix.

Sorry I'm just seeing your message coming home now from work,
but it seems that Karel already made a fix for it!