Fusermount3: user has no mount access to mountpoint (SSHFS)


I am using Manjaro XFCE and try to mount a directory with FFHS. I’m using the following entry in /etc/fstab from the example of the Arch wiki.

*user*@*host*:*/remote/path /local/path* fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/*user*/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0

But everytime the system boots I get the following error as soon as I want to access the mount directory with my user:

fusermount3: user has no write access to mountpoint /run/media/user/foldername

As soon as I run sudo chown myuser:myuser on the mount point, I can access the mount without any issues. But I have to do this every time I reboot. I checked the uid and gid with the “id” terminal command, so they are correct and should be set accordingly. But instead root gets set as owner.

The weird thing is I use the exact same line of the fstab in another Manjaro Linux system, but the Full version with KDE. This error happens under the minimal Version with XFCE. Weird is also that the XFCE version also prompted me to set “user_allow_other” in /etc/fuse.conf, which is not needed in my Manjaro KDE installation, even as already stated both use the exact same fstab entry.

I hope you can help me as I googled and tried but I don’t have any more ideas.

Hi @vommie,

I’m guessing this happens because everything in fstab gets mounted as root when the system starts up. According to this page you can change that by setting the uid and gid options for the mount. So changing it to:

*user*@*host*:*/remote/path /local/path* fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/*user*/.ssh/id_rsa,allow_other,default_permissions,uid=<user_id>,gid=<group_id> 0 0

Where <user_id> and <group_id> are the values that can be obtained by running

echo $UID


echo $GID


However, I’d suggest you switch to systemd mount units. I have a couple, and they all work an absolute charm.

Hope this helps!

:bangbang: Tip: :bangbang:

When posting terminal output, copy the output and paste it here, wrapped in three (3) backticks, before AND after the pasted text. Like this:

pasted text

Or three (3) tilde signs, like this:

pasted text

This will just cause it to be rendered like this:

sollicitudin dolor
eget nisl elit id
arcu erat varius
cursus sem quis eros.

Instead of like this:

Sed sollicitudin dolor eget nisl elit id condimentum arcu erat varius cursus sem quis eros.

Alternatively, paste the text you wish to format as terminal output, select all pasted text, and click the </> button on the taskbar. This will indent the whole pasted section with one TAB, causing it to render the same way as described above.

Thereby increasing legibility thus making it easier for those trying to provide assistance.

For more information, please see:

:bangbang::bangbang: Additionally

If your language isn’t English, please prepend any and all terminal commands with LC_ALL=C. For example:

LC_ALL=C bluetoothctl

This will just cause the terminal output to be in English, making it easier to understand and debug.

Hey @Mirdarthos, thanks for your answer. I already showed in the example and wrote in the text below that I’ve set the uid and gid. And as you can see in the fstab example, there is an x-systemd.automount which does, as the Wiki page says, “does the magic”.

But I’ve tried it with a systemd service but now I have another problem that I always get an error that the mount dir does not exist (it seems it does not get autocreated on boot, and if I create it by myself, it get’s deleted on reboot but not recreated).

I think it must work with the fstab. It works fine on my other systems too and when I google, a lot of people use fstab and also the Arch Wiki recommends it. :frowning:

Create the mount point manually, while the mount isn’t active. That should make it persistent. (Or that’s how mine is anyway. Also make sure that it’s not mounted somewhere volatile, like /run or /tmp.)

Thanks again. I already tried to remove the mount directory, it get’s recreated but it’s root:root again. It seems the fstab ignores the uid and gid. But I don’t get why (or if this is really the case).

If I run the command “id” I get this info:

uid=1000(vommie) gid=1001(vommie) groups=1001(vommie),3(sys),90(network),98(power),991(lp),998(wheel),1000(autologin)

And this is how my fstab entry looks:

vommie@server:/run/media/vommie/temp /run/media/vommie/temp fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/vommie/.ssh/vommie_rsa,allow_other,default_permissions,uid=1000,gid=1001 0 0

uid and gid is set there. And this fstab works, the dir gets mounted, only the mount point still gets the wrong user:group set on every reboot.

That’s specifically what I advised against:

…because /tmp is RAM, and AFAIK /run gets recreated at boot and if it’s the same on every boot, it’s pure luck and shouldn’t be relied on.


You should also change the server’s:

…to something more reliable it seems.

Probably because systemd-automount does not create the whole directory? As I know it just creates the last folder, so if /run/media is there, then it will not create /run/media/username/mountpoint, because the folder username is not there. It just tries to create mountpoint.

Here is my fstab line:

username@domain.name:/remote/path /run/media/username/mountpoint fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/username/.ssh/lima,allow_other,default_permissions,uid=1000,gid=1000,X-mount.mkdir=0755,x-gvfs-hide 0 0

I don’t use /run/media/username/mountpoint in practice, but I just tried it and it works. Maybe because of: X-mount.mkdir=0755 ?

Thanks for your efforts, but the problem in my opinion is not the location (which is used in every Arch article and automatically by the system for mounts), nor that the folder is removed or recreated at boot time, nor the access rights, but simply that the user “vommie” is not assigned while the share gets mounted. If I set it manually with chown I can access the folder for the session. And I use on other installations /run/media/… and fstab with sshfs for years without problems.

I tried “X-mount.mkdir=0755” but I guess that also only sets the permissions and not the owner. It didn’t work either unfortunately.

I will uninstall this Manjaro installation tonight (it’s a fresh install anyway) and use a “full image” instead of “minimal”, maybe just some package is missing or the XFCE version does something different than the KDE version I usually use (but also kinda weird)… :X

According to the Linux Foundation:


/run is another new directory. System processes use it to store temporary data for their own nefarious reasons. This is another one of those DO NOT TOUCH folders.

Yes. Not by humans.

Yeah. Because it shouldn’t be there.

As I previously said, it’s pure luck. And shouldn’t be relied on.

As you can see, it can work that way. But it isn’t intended to be used like that, so if anything goes amiss, you’re on your own.

A hint that it makes more sense to mount somewhere else is ok, but you’re acting like that’s the problem, which it definitely is not. "Pure luck … sure. The fstab dices.

And just for your info: I’ve changed the mount dir and the problem persists. Weird … how can this be? Seems /run was not the problem. Hm…

I’m thinking permissions. Ownership, user and group, and permissions. Both of the mountpoint, as well as the contents of the mounts.