Talk:SSHFS

Chrooting users

In my short experiences, chrooting a sftp user (with ForceCommand sftp-internal and ChrootDirectory /path/to/dir) requires that the Subsystem sftp <...> declaration use sftp-internal. If I'm wrong, please tell me, or else I will change the wiki to match (in a few days). -- Izzette (talk) 01:51, 9 June 2016 (UTC)

Add workaround

Maybe it will be useful to explain the option -o workaround=rename in order to overwrite file in the mounted system using kate, gedit, etc. Also when mounted using fstab

—This unsigned comment is by PogMat (talk) 21:39, 10 June 2016‎ (UTC). Please sign your posts with ~~~~!

Outdated/invalid option - default_permissions ?

mount option "default_permissions" is not in man page. Outdated wiki or wrong man page ? Or is "default_permissions" something general and not fuse releated? Thanks for clarification. Ua4000 (talk)

Add example using dpipe to do a reverse sshfs mount

Sometimes a reverse SSHFS mount can be useful. This is well described here: https://blog.dhampir.no/content/reverse-sshfs-mounts-fs-push. --Jose1711 (talk) 18:11, 27 July 2023 (UTC)

Missing explaination on sshfs helper fmount.py

In the tips several sshfs helpers are recommended. One of them is a link to a python script [https://github.com/lahwaacz/Scripts/blob/master/fmount.py fmount.py]. It is a piece of script in a git repo of a lot of such scripts and I find no useful documentation. This was added by its author User:Lahwaacz in Special:Diff/prev/484285. While appreciating the contribution of the sshfs helper, I would suggest the author or anyone familiar with it to add more information. I would also suggest that the script should be wrapped into a package with hash because giving such a link looks too prone to supplychain attack, though I know the fact that the author is an active maintainer of ArchWiki and AUR packages. Simonmysun (talk) 22:00, 21 July 2024 (UTC)

automount / systemd.automount / fstab change (Security)

I believe that section 4 is not described in a good and safe way as i believe how sshfs (fuse) should be used. I hope if my english explanations is not to bad and i can improve the entry at a later point or someone else could use these points to do a better job. Also i hope my understanding is not to wrong about it.

• FUSE (Filesystem in Userspace) should not be used by root (mount.fuse(8) SECURITY / see "4.4 Secure user access").
• sshfs should be used by a normal user and mounted under ${HOME}.

-> do not use fstab, reasons:

• systemd-fstab-generator only creates system-units not user-units.
• /etc/fstab entries generate .mount/.automount units for the system (root) not user. (see 4.1 "Accuracy box" )
• instead of "/etc/systemd/system/mnt-data.(auto/)mount" better use "${XDG_CONFIG_HOME}/systemd/user/home-foo-netmounts-data.{auto,}mount" or "${HOME}/.config/systemd/user/"
• use "systemctl --user "

I believe the best way to edit the article is for me to keep the old section as is for now, but with some disclaimers and minor changes. Bernd 007 (talk) 10:50, 12 December 2024 (UTC)

Example of systemd unit file (NOTE: The file needs to be named the same as local-mountpoint but with / replaced with - for example local mountpoint /sshfs/foo is named ssh-foo.mount)

[Unit]

Description=Mount my remote filesystem over sshfs with fuse

[Mount]

What=username@remote-host:remote-dir

Where=local-mountpoint

Type=fuse.sshfs

[Install]

WantedBy=default.target

--Harre (talk) 01:20, 25 February 2025 (UTC)

I am not sure if i understand this wrong, may be just a little misunderstanding. The systemd filename (i.e. in /etc or {HOME}.. ).../local-mountpoint.mount no "/" and the where= option must be a normal path. where=local-mountpoint seems wrong.

Note :systemd.mount(5) § DESCRIPTION Mount units must be named after the mount point directories they control. Example: the mount point /home/lennart must be configured in a unit file home-lennart.mount. For details about the escaping logic used to convert a file system path to a unit name, see systemd.unit(5). Note that mount units cannot be templated, nor is possible to add multiple names to a mount unit by creating symlinks to its unit file.

Note :systemd.mount(5) § OPTIONS Where= Takes an absolute path of a file or directory for the mount point; in particular, the destination cannot be a symbolic link. If the mount point does not exist at the time of mounting, it is created as either a directory or a file. The former is the usual case; the latter is done only if this mount is a bind mount and the source (What=) is not a directory. This string must be reflected in the unit filename. (See above.) This option is mandatory.

Bernd 007 (talk) 08:12, 10 May 2025 (UTC)

It's not possible to use automount for user mounts so you can instead make a service with ExecStart and ExecStop.

So this is a sample service:

[Unit]

Description=SSHFS Mount for remote-host

After=network.target

[Service]

Type=oneshot

ExecStart=/usr/bin/sshfs user@remote-host:remote-dir local-mountpoint

ExecStop=/bin/fusermount -u local-mountpoint

RemainAfterExit=yes

[Install]

WantedBy=default.target

--Harre (talk) 02:00, 25 February 2025 (UTC)

I am not sure but, i believe systemd's mount-unit is preferable to the service-unit. While this could work similar (not sure about RemainAfterExit=yes), i believe the mount-unit must do some things good or better. Bernd 007 (talk) 08:28, 10 May 2025 (UTC)

Although I concur in general with the security concerns, there are certain scenarios on private hosts, where such automounts are the easiest way. Experimenting myself I stumbled across some permission issues using systemd's .automunt units and drafted an addition to section 4.2. With your permission I would like to add this as 4.2.4

::Mountpoint ownership using systemd
::Despite the fact that systemd runs as root and therefore the .mount units as well, the actual fuse mount is done on behalf of the user defined in the .mount unit. Depending on the systemd version it creates non existent mountpoints and mounts an overlay of type autofs with preset permissions, by default owned by root
::You will see something like that in your mounts:
::systemd-1 on /mnt/data type autofs (rw,relatime,fd=41,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=414634)
::with the following permissions
::ls -l /mnt/
::drwxr-xr-x 2 root root 0 Jun 25 08:30 data
::regardless of a previously created mountpoint with adjusted permissions.
::In order for the .mount unit to be successful, you have to add at least some ExtraOptions to the [Automount] section of the .automount unit:
::ExtraOptions=uid=1000,gid=1000
::Use the same uid and gid you used in the .mount unit.

Christian.S (talk) 11:59, 26 June 2025 (UTC)

"Depending on the systemd version" does not make sense, Arch Linux has only one systemd version. — Lahwaacz (talk) 15:16, 29 June 2025 (UTC)

well, you may notice that not only Arch Linux user use the internet. I use Debian for example, but learned to love the Arch Linux wiki for information as it is most comprehensive. Guessing that 95 percent of the information found here applies to any Linux distribution, it might be useful to point out that detail. Christian.S (talk) 05:07, 30 June 2025 (UTC)