1 .\" Copyright (c) 2016 Julia Computing Inc, Keno Fischer
2 .\" Description based on include/uapi/fuse.h and code in fs/fuse
4 .\" %%%LICENSE_START(VERBATIM)
5 .\" Permission is granted to make and distribute verbatim copies of this
6 .\" manual provided the copyright notice and this permission notice are
7 .\" preserved on all copies.
9 .\" Permission is granted to copy and distribute modified versions of this
10 .\" manual under the conditions for verbatim copying, provided that the
11 .\" entire resulting derived work is distributed under the terms of a
12 .\" permission notice identical to this one.
14 .\" Since the Linux kernel and libraries are constantly changing, this
15 .\" manual page may be incorrect or out-of-date. The author(s) assume no
16 .\" responsibility for errors or omissions, or for damages resulting from
17 .\" the use of the information contained herein. The author(s) may not
18 .\" have taken the same level of care in the production of this manual,
19 .\" which is licensed free of charge, as they might when working
22 .\" Formatted or processed versions of this manual, if unaccompanied by
23 .\" the source, must acknowledge the copyright and authors of this work.
26 .TH FUSE 4 2018-02-02 "Linux" "Linux Programmer's Manual"
28 fuse \- Filesystem in Userspace (FUSE) device
31 .B #include <linux/fuse.h>
34 This device is the primary interface between the FUSE filesystem driver
35 and a user-space process wishing to provide the filesystem (referred to
36 in the rest of this manual page as the
37 .IR "filesystem daemon" ).
38 This manual page is intended for those
39 interested in understanding the kernel interface itself.
40 Those implementing a FUSE filesystem may wish to make use of
41 a user-space library such as
43 that abstracts away the low-level interface.
45 At its core, FUSE is a simple client-server protocol, in which the Linux
46 kernel is the client and the daemon is the server.
47 After obtaining a file descriptor for this device, the daemon may
49 requests from that file descriptor and is expected to
52 It is important to note that a file descriptor is
53 associated with a unique FUSE filesystem.
54 In particular, opening a second copy of this device,
55 will not allow access to resources created
56 through the first file descriptor (and vice versa).
58 .SS The basic protocol
59 Every message that is read by the daemon begins with a header described by
60 the following structure:
64 struct fuse_in_header {
65 uint32_t len; /* Total length of the data,
66 including this header */
67 uint32_t opcode; /* The kind of operation (see below) */
68 uint64_t unique; /* A unique identifier for this request */
69 uint64_t nodeid; /* ID of the filesystem object
71 uint32_t uid; /* UID of the requesting process */
72 uint32_t gid; /* GID of the requesting process */
73 uint32_t pid; /* PID of the requesting process */
79 The header is followed by a variable-length data portion
80 (which may be empty) specific to the requested operation
81 (the requested operation is indicated by
84 The daemon should then process the request and if applicable send
85 a reply (almost all operations require a reply; if they do not,
86 this is documented below), by performing a
88 to the file descriptor.
89 All replies must start with the following header:
93 struct fuse_out_header {
94 uint32_t len; /* Total length of data written to
95 the file descriptor */
96 int32_t error; /* Any error that occurred (0 if none) */
97 uint64_t unique; /* The value from the
98 corresponding request */
103 This header is also followed by (potentially empty) variable-sized
104 data depending on the executed request.
105 However, if the reply is an error reply (i.e.,
108 then no further payload data should be sent, independent of the request.
110 .SS Exchanged messages
111 This section should contain documentation for each of the messages
113 This manual page is currently incomplete,
114 so not all messages are documented.
115 For each message, first the struct sent by the kernel is given,
116 followed by a description of the semantics of the message.
122 struct fuse_init_in {
125 uint32_t max_readahead; /* Since protocol v7.6 */
126 uint32_t flags; /* Since protocol v7.6 */
131 This is the first request sent by the kernel to the daemon.
132 It is used to negotiate the protocol version and other filesystem parameters.
133 Note that the protocol version may affect the layout of any structure
134 in the protocol (including this structure).
135 The daemon must thus remember the negotiated version
136 and flags for each session.
137 As of the writing of this man page,
138 the highest supported kernel protocol version is
141 Users should be aware that the descriptions in this manual page
142 may be incomplete or incorrect for older or more recent protocol versions.
144 The reply for this request has the following format:
148 struct fuse_init_out {
151 uint32_t max_readahead; /* Since v7.6 */
152 uint32_t flags; /* Since v7.6; some flags bits
153 were introduced later */
154 uint16_t max_background; /* Since v7.13 */
155 uint16_t congestion_threshold; /* Since v7.13 */
156 uint32_t max_write; /* Since v7.5 */
157 uint32_t time_gran; /* Since v7.6 */
163 If the major version supported by the kernel is larger than that supported
164 by the daemon, the reply shall consist of only
166 (following the usual header),
167 indicating the largest major version supported by the daemon.
168 The kernel will then issue a new
170 request conforming to the older version.
171 In the reverse case, the daemon should
172 quietly fall back to the kernel's major version.
174 The negotiated minor version is considered to be the minimum
175 of the minor versions provided by the daemon and the kernel and
176 both parties should use the protocol corresponding to said minor version.
182 struct fuse_getattr_in {
183 uint32_t getattr_flags;
185 uint64_t fh; /* Set only if
186 (getattr_flags & FUSE_GETATTR_FH)
191 The requested operation is to compute the attributes to be returned
194 and similar operations for the given filesystem object.
195 The object for which the attributes should be computed is indicated
200 flag is set, by the file handle
202 The latter case of operation is analogous to
205 For performance reasons, these attributes may be cached in the kernel for
206 a specified duration of time.
207 While the cache timeout has not been exceeded,
208 the attributes will be served from the cache and will not cause additional
212 The computed attributes and the requested
213 cache timeout should then be returned in the following structure:
217 struct fuse_attr_out {
218 /* Attribute cache duration (seconds + nanoseconds) */
220 uint32_t attr_valid_nsec;
248 struct fuse_access_in {
256 .I default_permissions
257 mount options is not used, this request may be used for permissions checking.
258 No reply data is expected, but errors may be indicated
259 as usual by setting the
261 field in the reply header (in particular, access denied errors
262 may be indicated by returning
265 .BR FUSE_OPEN " and " FUSE_OPENDIR
268 struct fuse_open_in {
269 uint32_t flags; /* The flags that were passed
276 The requested operation is to open the node indicated by
277 .IR header\->nodeid .
278 The exact semantics of what this means will depend on the
279 filesystem being implemented.
280 However, at the very least the
281 filesystem should validate that the requested
283 are valid for the indicated resource and then send a reply with the
288 struct fuse_open_out {
298 field is an opaque identifier that the kernel will use to refer
302 field is a bit mask of any number of the flags
303 that indicate properties of this file handle to the kernel:
307 Bypass page cache for this open file.
310 Don't invalidate the data cache on open.
312 .BR FOPEN_NONSEEKABLE
313 The file is not seekable.
316 .BR FUSE_READ " and " FUSE_READDIR
320 struct fuse_read_in {
332 The requested action is to read up to
334 bytes of the file or directory, starting at
336 The bytes should be returned directly following the usual reply header.
341 struct fuse_interrupt_in {
347 The requested action is to cancel the pending operation indicated by
349 This request requires no response.
350 However, receipt of this message does
351 not by itself cancel the indicated operation.
352 The kernel will still expect a reply to said operation (e.g., an
354 error or a short read).
357 request will be issued for a given operation.
358 After issuing said operation,
359 the kernel will wait uninterruptibly for completion of the indicated request.
362 Directly following the header is a filename to be looked up in the directory
364 .IR header\->nodeid .
365 The expected reply is of the form:
369 struct fuse_entry_out {
370 uint64_t nodeid; /* Inode ID */
371 uint64_t generation; /* Inode generation */
372 uint64_t entry_valid;
374 uint32_t entry_valid_nsec;
375 uint32_t attr_valid_nsec;
376 struct fuse_attr attr;
385 must be unique for the filesystem's lifetime.
387 The interpretation of timeouts and
395 struct fuse_flush_in {
404 The requested action is to flush any pending changes to the indicated
406 No reply data is expected.
407 However, an empty reply message
408 still needs to be issued once the flush operation is complete.
410 .BR FUSE_RELEASE " and " FUSE_RELEASEDIR
413 struct fuse_release_in {
416 uint32_t release_flags;
422 These are the converse of
427 The daemon may now free any resources associated with the
430 as the kernel will no longer refer to it.
431 There is no reply data associated with this request,
432 but a reply still needs to be issued once the request has
433 been completely processed.
436 This operation implements
439 There is no input data associated with this request.
440 The expected reply data has the following structure:
444 struct fuse_kstatfs {
457 struct fuse_statfs_out {
458 struct fuse_kstatfs st;
463 For the interpretation of these fields, see
470 operations when the kernel's request is too large for the provided buffer
477 if validation of the reply failed.
478 Not all mistakes in replies will be caught by this validation.
479 However, basic mistakes, such as short replies or an incorrect
486 operations when the kernel's request is too large for the provided buffer.
489 There are various ways in which incorrect use of these interfaces can cause
490 operations on the provided filesystem's files and directories to fail with
492 Among the possible incorrect uses are:
497 for an inode that has previously been reported to the kernel; or
499 giving replies to the kernel that are shorter than what the kernel expected.
507 if the FUSE filesystem was unmounted.
510 Returned from operations on a
512 file descriptor that has not been mounted.
514 The FUSE filesystem is Linux-specific.
516 The following messages are not yet documented in this manual page:
518 .\" FIXME: Document the following.
521 .BR FUSE_BATCH_FORGET
537 .BR FUSE_NOTIFY_REPLY