FS#71650 - Manual SSHFS mounts defined in /etc/fstab fail

Attached to Project: Arch Linux
Opened by David Parrish (dmp1ce) - Thursday, 29 July 2021, 11:48 GMT
Last edited by Christian Heusel (gromit) - Monday, 28 August 2023, 08:41 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I had several fuse.sshfs mounts defined in /etc/fstab but they all stopped working after a recent update. My /etc/fstab lines look like this:

david@server:/home/david/VideoProjects /mnt/server/VideoProjects fuse.sshfs noauto,defaults,_netdev,idmap=user 0 0

I normally could `mount /mnt/serer/VideoProjects` and the sshfs mount works.

When I try `mount /mnt/serer/VideoProjects` now the command immediately returns to the prompt with a 1 return code.

Additional info:

Attached is my pacman.log just before the mounts stopped working.

I couldn't find any upstream issues.

Steps to reproduce:

1. Setup a network sshfs mount using fstab.
2. Try to manually mount the sshfs network mount using the `mount` command.
   KFFQ.txt (13.2 KiB)
This task depends upon

Closed by  Christian Heusel (gromit)
Monday, 28 August 2023, 08:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  User reports that the problem is gone
Comment by michael (msch) - Tuesday, 03 August 2021, 16:19 GMT
Same here, a plain "mount /mnt/something/" stopped working after my recent system update. I get the following error message: "fuse: failed to open /dev/fuse: Permission denied", which is different from what David Parrish experienced. This is how the relevant line in /etc/fstab looks like:

vault@sftp.server.com:/users/vault/ /mnt/something/ sshfs workaround=rename,noauto,user 0 0

I also attached an excerpt of pacman.log, covering the latest update.
Comment by michael (msch) - Friday, 06 August 2021, 08:56 GMT
I found out that i had a custom udev rule in /etc/udev/rules.d/ which set the wrong MODE on /dev/fuse. The file /lib/udev/rules.d/99-fuse.rules will set a mode of 0666 on /dev/fuse, but my custom rule changed it to be 0660. As /dev/fuse has root as the owner and root as the group, my regular user had no permission to use the device anymore. I fixed my custom rule and SSHFS mounts now work as expected.

@David Parrish: Maybe you have a different issue, but could you check the permissions of /dev/fuse right after boot? Maybe some udev rules of yours started interfering with the device too.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 06 August 2021, 14:07 GMT
This looks more like a fuse issue than a sshfs issue to me.
Comment by David Parrish (dmp1ce) - Sunday, 08 August 2021, 12:24 GMT
@msch I don't have a /dev/fuse for some reason. 🤷
Comment by David Parrish (dmp1ce) - Sunday, 08 August 2021, 12:26 GMT
The only custom udev rules I have in /et/udev/rules.d/ are Snap rules installed from the AUR snapd package.
Comment by David Parrish (dmp1ce) - Sunday, 08 August 2021, 13:31 GMT
I'm not sure what to make of the kernel and system messages. It looks like fuse service is stopping.

I attached relevant `journalctl -b` results.
   D33A.txt (7.1 KiB)
Comment by michael (msch) - Sunday, 08 August 2021, 17:19 GMT
I believe /dev/fuse should be present for SSHFS to work. Do you get an error message when you try to load the module using 'modprobe fuse' as root?
Comment by David Parrish (dmp1ce) - Monday, 09 August 2021, 00:53 GMT
Mounts are working for me now. I have no idea why. I didn't change anything except for doing `pacman -Syu` updates.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 09 August 2021, 13:26 GMT
Could it be the case you updated the kernel and forgot to reboot?
Comment by David Parrish (dmp1ce) - Monday, 09 August 2021, 13:36 GMT
I'm sure the kernel did get updated once or twice. I tried to reboot every time.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...