NAME
|
sshfs – secure file transfer protocol client |
SYNOPSIS
sshfs [ –abdRUGM ] [ –s service ] [ –m mtpt ] [ –r root ] [ –u uidfile
] [ –g gidfile ]
|
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 service 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 untranslated.
Further options: |
SOURCE
|
/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 supported 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 particular 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 distinct 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) |