libfuse/doc
2024-08-07 10:12:12 +02:00
..
.gitignore Include documentation in tarball. 2016-01-28 18:01:48 -08:00
Doxyfile Fix doxygen deprecation warning (#774) 2023-04-12 09:10:12 +01:00
fast17-vangoor.pdf Added some documentation of fuse internals. 2017-09-17 09:35:43 +01:00
fusermount3.1 doc: Add "fuse (4)" to SEE ALSO sections in man pages (#601) 2021-05-08 14:15:55 +01:00
kernel.txt Doc fixes (#537) 2020-08-09 12:35:28 +01:00
libfuse-operations.txt doc/libfuse-operations: Fix FUSE_STATX in_args[1] description 2024-08-07 10:12:12 +02:00
mainpage.dox Added some documentation of fuse internals. 2017-09-17 09:35:43 +01:00
meson.build Fix manpage filename for mount.fuse3 2018-07-04 19:52:32 +01:00
mount.fuse3.8 high-level: add fmask and dmask options 2024-07-03 12:50:06 +02:00
README.NFS Add more documentation for FUSE_CAP_EXPORT_SUPPORT (#917) 2024-04-02 23:52:18 +02:00

NFS exporting is supported in Linux kernels 2.6.27 or later.

You need to add an fsid=NNN option to /etc/exports to make exporting a
FUSE directory work.

Filesystem support
------------------

NFS exporting works to some extent on all fuse filesystems, but not
perfectly.  This is due to the stateless nature of the protocol, the
server has no way of knowing whether the client is keeping a reference
to a file or not, and hence that file may be removed from the server's
cache.  In that case there has to be a way to look up that object
using the inode number, otherwise an ESTALE error will be returned.

1) low-level interface

Filesystems need to set FUSE_CAP_EXPORT_SUPPORT in conn->wants and
implement special lookups for the names "." and "..". The former may
be requested on any inode, including non-directories, while the latter
is only requested for directories.  Otherwise these special lookups
should behave identically to ordinary lookups.

Furthermore, setting FUSE_CAP_EXPORT_SUPPORT requires the file system
to handle node-ids (fuse_ino_t) that the file system may does not know
about - e.g. a fuse FORGET request might have been received or the node-id
was used in a previous instance of the file system daemon. The node-id might
not be valid at all when an invalid handle is passed to open_by_handle_at(). 
This implies that the filesystem *must not* reuse node-ids even if
generation numbers are set correctly. This is because generation numbers
are not provided by the kernel to e.g. the getattr() handler, so the
handler would be unable to tell if the provided node-id refers to the
"known" current one, or a previous one that has been forgotten and re-used.

2) high-level interface

Because the high-level interface is path based, it is not possible to
delegate looking up by inode to the filesystem.

To work around this, currently a "noforget" option is provided, which
makes the library remember nodes forever.  This will make the NFS
server happy, but also results in an ever growing memory footprint for
the filesystem.  For this reason if the filesystem is large (or the
memory is small), then this option is not recommended.