tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

Delete text about old bugs that are not relevant for Tahoe 1.10.0+ 

[Imported from Trac: page SftpFrontend, version 94]
daira 2017-02-05 12:14:32 +00:00
parent 81c93a8f97
commit dbc3d2134a
1 changed files with 2 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
SftpFrontend.md

@ -1,6 +1,6 @@
The SFTP frontend is a server that optionally runs as part of a gateway node, and provides read/write access to the Tahoe grid via the [SSH File Transfer Protocol](http://en.wikipedia.org/wiki/SSH_file_transfer_protocol). The SFTP frontend is a server that optionally runs as part of a gateway node, and provides read/write access to the Tahoe grid via the [SSH File Transfer Protocol](http://en.wikipedia.org/wiki/SSH_file_transfer_protocol).
See [docs/frontends/FTP-and-SFTP.rst (.txt in releases before v1.8.1)](http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.rst) for how to enable and set up the SFTP frontend on a gateway. This page is for compatibility issues with particular SFTP clients, and assumes that you are using Tahoe-LAFS v1.7.0 or later. Please add any more issues that you discover. See [docs/frontends/FTP-and-SFTP.rst for how to enable and set up the SFTP frontend on a gateway. This page is for compatibility issues with particular SFTP clients, and assumes that you are using Tahoe-LAFS v1.10.0 or later. (We do not recommend that you use SFTP with earlier versions of Tahoe.) Please add any more issues that you discover.
# Security # Security
@ -22,16 +22,12 @@ In the period after the close but before the upload has finished, the closed fil
Since Tahoe uses capability access control rather than Unix-style permissions, the permission bits seen by SFTP clients are only an approximation chosen to avoid confusing client programs. In particular the 'user', 'group' and 'world' permissions on a Tahoe file will always be the same. It is possible to clear all of the 'w' bits on a file, which will prevent that file from being opened for writing, but note that its directory entry can still be replaced via a write cap to the directory. Since Tahoe uses capability access control rather than Unix-style permissions, the permission bits seen by SFTP clients are only an approximation chosen to avoid confusing client programs. In particular the 'user', 'group' and 'world' permissions on a Tahoe file will always be the same. It is possible to clear all of the 'w' bits on a file, which will prevent that file from being opened for writing, but note that its directory entry can still be replaced via a write cap to the directory.
See the last section of [docs/frontends/FTP-and-SFTP.rst](http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.rst) for information on how the SFTP frontend treats immutable and mutable files. See the last section of [<http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.rst> docs/frontends/FTP-and-SFTP.rst](http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.rst) for information on how the SFTP frontend treats immutable and mutable files.
Deleting a directory via the SFTP frontend will not check that it is empty. The directory will be unlinked from its parent, but its contents will remain accessible via any other capabilities to it. Deleting a directory via the SFTP frontend will not check that it is empty. The directory will be unlinked from its parent, but its contents will remain accessible via any other capabilities to it.
The '`ctime`' and '`mtime`' attributes will always be the same, and are set from the Tahoe `linkmotime` timestamp, which is changed only when the link from the parent directory is modified (see the ['About the metadata' section of webapi.rst](http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/webapi.rst#about-the-metadata)). These fields are not updated when the contents of a mutable file are changed. The SFTP protocol and the server are able to represent dates up to the year 2106, but some clients may print dates after 2037 incorrectly. The '`ctime`' and '`mtime`' attributes will always be the same, and are set from the Tahoe `linkmotime` timestamp, which is changed only when the link from the parent directory is modified (see the ['About the metadata' section of webapi.rst](http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/webapi.rst#about-the-metadata)). These fields are not updated when the contents of a mutable file are changed. The SFTP protocol and the server are able to represent dates up to the year 2106, but some clients may print dates after 2037 incorrectly.
Versions of Twisted before v11.0 have [a bug in support for rekeying](http://twistedmatrix.com/trac/ticket/4395). Tahoe-LAFS v1.10.0 requires a later version of Twisted and so will not be affected by this problem. For earlier versions of Tahoe-LAFS, it is recommended to install a version of Twisted between v11.0 and v12.2 inclusive (and use `tahoe --version` to check that it is being used); otherwise, this bug might cause a hang or 100% CPU usage by the gateway when a client tries to rekey. Depending on the client, rekeying may be triggered based on a time interval or the amount of data sent (for example, 1 GiB to 4 GiB for the openssh client), so this problem may not happen immediately when testing.
Version v12.3 of Twisted is incompatible with the SFTP frontend (#1926, #1525). Upgrade to Tahoe-LAFS v1.10.0 to fix this problem.
# Unicode filenames # Unicode filenames
@ -70,8 +66,6 @@ If a file in a mutable directory is closed concurrently with an operation that n
A POSIX application might assume that deleting a non-empty directory will fail, when it does not on a Tahoe filesystem (#1362). A POSIX application might assume that deleting a non-empty directory will fail, when it does not on a Tahoe filesystem (#1362).
To avoid potential bugs with rekeying, check that the version of Twisted shown by `tahoe --version-and-path` is at least 11.0. If not, install a more recent version of Twisted. This will not be an issue for Tahoe-LAFS v1.10 or later.
To unmount an sshfs filesystem, make sure you are in the `fuse` group (if necessary use "`sudo adduser `whoami` fuse`"), and then do "`fusermount -u mountpoint`". To unmount an sshfs filesystem, make sure you are in the `fuse` group (if necessary use "`sudo adduser `whoami` fuse`"), and then do "`fusermount -u mountpoint`".
If you encounter problems, please use the debugging options `-o debug,sshfs_debug,loglevel=debug` and send the resulting log to the `tahoe-dev` list. Also the log output from the gateway, which can be captured as described at source:docs/logging.rst, may be helpful. If you encounter problems, please use the debugging options `-o debug,sshfs_debug,loglevel=debug` and send the resulting log to the `tahoe-dev` list. Also the log output from the gateway, which can be captured as described at source:docs/logging.rst, may be helpful.