{
    "mode": "man",
    "parameter": "fuse",
    "section": "4",
    "url": "https://www.chedong.com/phpMan.php/man/fuse/4/json",
    "generated": "2026-05-30T07:07:29Z",
    "synopsis": "",
    "sections": {
        "NAME": {
            "content": "fuse - Filesystem in Userspace (FUSE) device\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "",
            "subsections": [
                {
                    "name": "#include <linux/fuse.h>",
                    "content": ""
                }
            ]
        },
        "DESCRIPTION": {
            "content": "This  device  is  the  primary  interface between the FUSE filesystem driver and a user-space\nprocess wishing to provide the filesystem (referred to in the rest of this manual page as the\nfilesystem  daemon).   This manual page is intended for those interested in understanding the\nkernel interface itself.  Those implementing a FUSE filesystem may wish  to  make  use  of  a\nuser-space library such as libfuse that abstracts away the low-level interface.\n\nAt its core, FUSE is a simple client-server protocol, in which the Linux kernel is the client\nand the daemon is the server.  After obtaining a file descriptor for this device, the  daemon\nmay  read(2) requests from that file descriptor and is expected to write(2) back its replies.\nIt is important to note that a file descriptor is associated with a unique  FUSE  filesystem.\nIn  particular, opening a second copy of this device, will not allow access to resources cre‐\nated through the first file descriptor (and vice versa).\n",
            "subsections": [
                {
                    "name": "The basic protocol",
                    "content": "Every message that is read by the daemon begins with a  header  described  by  the  following\nstructure:\n\nstruct fuseinheader {\nuint32t len;       /* Total length of the data,\nincluding this header */\nuint32t opcode;    /* The kind of operation (see below) */\nuint64t unique;    /* A unique identifier for this request */\nuint64t nodeid;    /* ID of the filesystem object\nbeing operated on */\nuint32t uid;       /* UID of the requesting process */\nuint32t gid;       /* GID of the requesting process */\nuint32t pid;       /* PID of the requesting process */\nuint32t padding;\n};\n\nThe header is followed by a variable-length data portion (which may be empty) specific to the\nrequested operation (the requested operation is indicated by opcode).\n\nThe daemon should then process the request and if applicable send a reply (almost all  opera‐\ntions require a reply; if they do not, this is documented below), by performing a write(2) to\nthe file descriptor.  All replies must start with the following header:\n\nstruct fuseoutheader {\nuint32t len;       /* Total length of data written to\nthe file descriptor */\nint32t  error;     /* Any error that occurred (0 if none) */\nuint64t unique;    /* The value from the\ncorresponding request */\n};\n\nThis header is also followed by (potentially empty) variable-sized data depending on the exe‐\ncuted request.  However, if the reply is an error reply (i.e., error is set), then no further\npayload data should be sent, independent of the request.\n"
                },
                {
                    "name": "Exchanged messages",
                    "content": "This section should contain documentation for each of the messages  in  the  protocol.   This\nmanual  page  is currently incomplete, so not all messages are documented.  For each message,\nfirst the struct sent by the kernel is given, followed by a description of the  semantics  of\nthe message.\n\nFUSEINIT\n\nstruct fuseinitin {\nuint32t major;\nuint32t minor;\nuint32t maxreadahead; /* Since protocol v7.6 */\nuint32t flags;         /* Since protocol v7.6 */\n};\n\nThis  is  the first request sent by the kernel to the daemon.  It is used to negotiate\nthe protocol version and other filesystem parameters.  Note that the protocol  version\nmay  affect  the  layout  of any structure in the protocol (including this structure).\nThe daemon must thus remember the negotiated version and flags for each  session.   As\nof  the  writing  of  this  man page, the highest supported kernel protocol version is\n7.26.\n\nUsers should be aware that the descriptions in this manual page may be  incomplete  or\nincorrect for older or more recent protocol versions.\n\nThe reply for this request has the following format:\n\nstruct fuseinitout {\nuint32t major;\nuint32t minor;\nuint32t maxreadahead;   /* Since v7.6 */\nuint32t flags;           /* Since v7.6; some flags bits\nwere introduced later */\nuint16t maxbackground;  /* Since v7.13 */\nuint16t congestionthreshold;  /* Since v7.13 */\nuint32t maxwrite;       /* Since v7.5 */\nuint32t timegran;       /* Since v7.6 */\nuint32t unused[9];\n};\n\nIf the major version supported by the kernel is larger than that supported by the dae‐\nmon, the reply shall consist of only uint32t major (following the usual header),  in‐\ndicating  the largest major version supported by the daemon.  The kernel will then is‐\nsue a new FUSEINIT request conforming to the older version.  In the reverse case, the\ndaemon should quietly fall back to the kernel's major version.\n\nThe  negotiated  minor  version  is considered to be the minimum of the minor versions\nprovided by the daemon and the kernel and both parties should use the protocol  corre‐\nsponding to said minor version.\n\nFUSEGETATTR\n\nstruct fusegetattrin {\nuint32t getattrflags;\nuint32t dummy;\nuint64t fh;      /* Set only if\n(getattrflags & FUSEGETATTRFH)\n};\n\nThe  requested  operation  is  to compute the attributes to be returned by stat(2) and\nsimilar operations for the given filesystem object.  The  object  for  which  the  at‐\ntributes  should  be  computed  is  indicated  either  by  header->nodeid  or,  if the\nFUSEGETATTRFH flag is set, by the file handle fh.  The latter case of  operation  is\nanalogous to fstat(2).\n\nFor  performance reasons, these attributes may be cached in the kernel for a specified\nduration of time.  While the cache timeout has not been exceeded, the attributes  will\nbe served from the cache and will not cause additional FUSEGETATTR requests.\n\nThe computed attributes and the requested cache timeout should then be returned in the\nfollowing structure:\n\nstruct fuseattrout {\n/* Attribute cache duration (seconds + nanoseconds) */\nuint64t attrvalid;\nuint32t attrvalidnsec;\nuint32t dummy;\nstruct fuseattr {\nuint64t ino;\nuint64t size;\nuint64t blocks;\nuint64t atime;\nuint64t mtime;\nuint64t ctime;\nuint32t atimensec;\nuint32t mtimensec;\nuint32t ctimensec;\nuint32t mode;\nuint32t nlink;\nuint32t uid;\nuint32t gid;\nuint32t rdev;\nuint32t blksize;\nuint32t padding;\n} attr;\n};\n\nFUSEACCESS\n\nstruct fuseaccessin {\nuint32t mask;\nuint32t padding;\n};\n\nIf the defaultpermissions mount options is not used, this request  may  be  used  for\npermissions checking.  No reply data is expected, but errors may be indicated as usual\nby setting the error field in the reply header (in particular,  access  denied  errors\nmay be indicated by returning -EACCES).\n\nFUSEOPEN and FUSEOPENDIR\nstruct fuseopenin {\nuint32t flags;     /* The flags that were passed\nto the open(2) */\nuint32t unused;\n};\n\nThe  requested  operation  is to open the node indicated by header->nodeid.  The exact\nsemantics of what this means will depend on the filesystem  being  implemented.   How‐\never,  at  the  very least the filesystem should validate that the requested flags are\nvalid for the indicated resource and then send a reply with the following format:\n\nstruct fuseopenout {\nuint64t fh;\nuint32t openflags;\nuint32t padding;\n};\n\nThe fh field is an opaque identifier that the kernel will use to  refer  to  this  re‐\nsource  The  openflags  field  is a bit mask of any number of the flags that indicate\nproperties of this file handle to the kernel:\n\nFOPENDIRECTIO   Bypass page cache for this open file.\n\nFOPENKEEPCACHE  Don't invalidate the data cache on open.\n\nFOPENNONSEEKABLE The file is not seekable.\n\nFUSEREAD and FUSEREADDIR\n\nstruct fusereadin {\nuint64t fh;\nuint64t offset;\nuint32t size;\nuint32t readflags;\nuint64t lockowner;\nuint32t flags;\nuint32t padding;\n};\n\nThe requested action is to read up to size bytes of the file or directory, starting at\noffset.  The bytes should be returned directly following the usual reply header.\n\nFUSEINTERRUPT\nstruct fuseinterruptin {\nuint64t unique;\n};\n\nThe requested action is to cancel the pending operation indicated by unique.  This re‐\nquest requires no response.  However, receipt of this message does not by itself  can‐\ncel  the  indicated operation.  The kernel will still expect a reply to said operation\n(e.g., an EINTR error or a short read).  At most one FUSEINTERRUPT  request  will  be\nissued  for a given operation.  After issuing said operation, the kernel will wait un‐\ninterruptibly for completion of the indicated request.\n\nFUSELOOKUP\nDirectly following the header is a filename to be looked up in the directory indicated\nby header->nodeid.  The expected reply is of the form:\n\nstruct fuseentryout {\nuint64t nodeid;            /* Inode ID */\nuint64t generation;        /* Inode generation */\nuint64t entryvalid;\nuint64t attrvalid;\nuint32t entryvalidnsec;\nuint32t attrvalidnsec;\nstruct fuseattr attr;\n};\n\nThe combination of nodeid and generation must be unique for the filesystem's lifetime.\n\nThe interpretation of timeouts and attr is as for FUSEGETATTR.\n\nFUSEFLUSH\nstruct fuseflushin {\nuint64t fh;\nuint32t unused;\nuint32t padding;\nuint64t lockowner;\n};\n\nThe requested action is to flush any pending changes to the indicated file handle.  No\nreply data is expected.  However, an empty reply message still needs to be issued once\nthe flush operation is complete.\n\nFUSERELEASE and FUSERELEASEDIR\nstruct fusereleasein {\nuint64t fh;\nuint32t flags;\nuint32t releaseflags;\nuint64t lockowner;\n};\n\nThese are the converse of FUSEOPEN and FUSEOPENDIR respectively.  The daemon may now\nfree any resources associated with the file handle fh as the kernel will no longer re‐\nfer  to  it.   There  is no reply data associated with this request, but a reply still\nneeds to be issued once the request has been completely processed.\n\nFUSESTATFS\nThis operation implements statfs(2) for this filesystem.  There is no input data asso‐\nciated with this request.  The expected reply data has the following structure:\n\nstruct fusekstatfs {\nuint64t blocks;\nuint64t bfree;\nuint64t bavail;\nuint64t files;\nuint64t ffree;\nuint32t bsize;\nuint32t namelen;\nuint32t frsize;\nuint32t padding;\nuint32t spare[6];\n};\n\nstruct fusestatfsout {\nstruct fusekstatfs st;\n};\n\nFor the interpretation of these fields, see statfs(2).\n"
                }
            ]
        },
        "ERRORS": {
            "content": "E2BIG  Returned  from  read(2) operations when the kernel's request is too large for the pro‐\nvided buffer and the request was FUSESETXATTR.\n\nEINVAL Returned from write(2) if validation of the reply failed.  Not all mistakes in replies\nwill  be caught by this validation.  However, basic mistakes, such as short replies or\nan incorrect unique value, are detected.\n\nEIO    Returned from read(2) operations when the kernel's request is too large for  the  pro‐\nvided buffer.\n\nNote:  There are various ways in which incorrect use of these interfaces can cause op‐\nerations on the provided filesystem's files and directories to fail with  EIO.   Among\nthe possible incorrect uses are:\n\n*  changing  mode  & SIFMT for an inode that has previously been reported to the ker‐\nnel; or\n\n*  giving replies to the kernel that are shorter than what the kernel expected.\n\nENODEV Returned from read(2) and write(2) if the FUSE filesystem was unmounted.\n\nEPERM  Returned from operations on a /dev/fuse file descriptor that has not been mounted.\n",
            "subsections": []
        },
        "CONFORMING TO": {
            "content": "The FUSE filesystem is Linux-specific.\n",
            "subsections": []
        },
        "NOTES": {
            "content": "The following messages are not yet documented in this manual page:\n\nFUSEBATCHFORGET\nFUSEBMAP\nFUSECREATE\nFUSEDESTROY\nFUSEFALLOCATE\nFUSEFORGET\nFUSEFSYNC\nFUSEFSYNCDIR\nFUSEGETLK\nFUSEGETXATTR\nFUSEIOCTL\nFUSELINK\nFUSELISTXATTR\nFUSELSEEK\nFUSEMKDIR\nFUSEMKNOD\nFUSENOTIFYREPLY\nFUSEPOLL\nFUSEREADDIRPLUS\nFUSEREADLINK\nFUSEREMOVEXATTR\nFUSERENAME\nFUSERENAME2\nFUSERMDIR\nFUSESETATTR\nFUSESETLK\nFUSESETLKW\nFUSESYMLINK\nFUSEUNLINK\nFUSEWRITE\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "fusermount(1), mount.fuse(8)\n",
            "subsections": []
        },
        "COLOPHON": {
            "content": "This page is part of release 5.10 of the Linux  man-pages  project.   A  description  of  the\nproject,  information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux                                        2018-02-02                                      FUSE(4)",
            "subsections": []
        }
    },
    "summary": "fuse - Filesystem in Userspace (FUSE) device",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "fusermount",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/fusermount/1/json"
        },
        {
            "name": "mount.fuse",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/mount.fuse/8/json"
        }
    ]
}