SSHFS(4) SSHFS(4)
NAME
sshfs - secure file transfer protocol client
SYNOPSIS
sshfs [ -abdRUGM ] [ -s service ] [ -m mtpt ] [ -r root ] [
-u uidfile ] [ -g gidfile ]
[ -- ssh-options ] [user@]host | -c cmdline | -p
DESCRIPTION
Sshfs makes the file system on a remote host accessible
through the secure file transfer protocol (SFTP). By
default sshfs launches ssh(1) to connect to host and log in
as user. If -c is specified, sshfs will instead launch the
command specified by cmdline and if -p is specified, sshfs
communicates with an SFTP server via stdin and stdout.
Unless -M is specified, sshfs will mount itself at the
mountpoint specified by mtpt, or at /n/ssh if -m is not
specified. The default mount options are equivalent to
calling mount (see bind(1)) with -c. -a and -b have the
same function as they do with mount.
If -s is specified, it will post itself in srv(3) with ser-
vice name service. If the service file is mounted, the
attach name (the third argument to mount(1)) can be used to
specify which directory on the remote host will be mounted.
By default, relative paths are assumed relative to the
user's home directory. The -r option can be used to specify
an alternative base for relative paths. The initial mount
at -m also uses this directory. If an attach name starts
with ~, the user's home directory is substituted for ~.
Since the only supported version 3 of the SFTP protocol has
no way to look up numeric user and group IDs, sshfs will
read the files /etc/passwd and /etc/group on the remote host
to create a lookup table for them. The location of these
files can be changed with -u and -g, whereas -U and -G will
inhibit reading them entirely. If these files cannot be
accessed for any reason, numeric IDs simply remain untrans-
lated.
Further options:
-R Read access only.
-d Enable debugging output.
SOURCE
Page 1 Plan 9 (printed 12/22/24)
SSHFS(4) SSHFS(4)
/sys/src/cmd/sshfs.c
BUGS
Currently only version 3 of the SFTP protocol is supported
(which is the most common version in use and the latest sup-
ported by openssh). Unfortunately there are problems with
the version 3 specification and the code relies on openssh-
specific behaviour in some corner cases. Version 4 and
later also handle uid/gid translation at the server end
which would remove the ugly dependence on reading remote
configuration files.
Some 9P operations that should be atomic are not atomic
because they do not map 1:1 to SFTP operations. In particu-
lar there is no guarantee that a failed wstat (see stat(5))
did not change some of the fields.
The code is naive about links and assumes files with dis-
tinct names to be distinct, assigning them different QIDs.
File names with null bytes in them will confuse sshfs. Sshfs
should probably escape them, as well as control characters
that might confuse other software.
HISTORY
Sshfs first appeared in 9front (Apr, 2017).
SEE ALSO
ssh(1)
Page 2 Plan 9 (printed 12/22/24)