VIRTIOFSD(1)

📦
version 7.2 · 6 versions
, in debian bookworm

💖 VIRTIOFSD 💖

okay bestie, welcome to the virtiofsd page — that's VIRTIOFSD(1) if you're being fancy, a.k.a. the QEMU virtio-fs shared file system daemon. it's a whole mood and it's about to hand your guest VM a slice of your host's filesystem like it's passing you aux at lunch. 🍓

✨ SYNOPSIS ✨

virtiofsd [OPTIONS]

that's it. that's the whole invocation. iconic behavior honestly. 💅

🌈 DESCRIPTION 🌈

so here's the tea 🫖 — virtiofsd shares a host directory tree with a guest through a virtio-fs device. it's a vhost-user backend that implements the virtio-fs device, and every single virtio-fs device instance needs its own virtiofsd process. no sharing processes, no group projects, everyone gets their own. 🙅♀️

this program is designed to work with QEMU's --device vhost-user-fs-pci, but fr fr it should work with any virtual machine monitor (VMM) that supports vhost-user. check the Examples section below for the receipts. 👑

big one: this program must be run as the root user. yeah. root. like, that's the vibe check it demands.

now, it does drop privileges where possible during startup, but lowkey it still needs the ability to create and access files with any uid/gid. the way it locks itself down:

in "namespace" sandbox mode the program switches into a new file system namespace and invokes pivot_root(2) to make the shared directory tree its root. a new pid and net namespace is also created to isolate the process. main character isolation energy. 🧚

in "chroot" sandbox mode the program invokes chroot(2) to make the shared directory tree its root. this mode is intended for container environments where the container runtime has already set up the namespaces and the program does not have permission to create namespaces itself. it's giving "i'm a guest in your house, not the homeowner". 🏠

and both sandbox modes? they prevent "file system escapes" due to symlinks and other file system objects that might lead to files outside the shared directory. so nobody's sneaking out the back door. 🚪✨

💅 OPTIONS 💅

  • -h, --help — print help. simple. slay.
  • -V, --version — print version. the receipts of which build you're on. ⭐
  • -d — enable debug output. turn the volume up on the logs. 🔊
  • --syslog — print log messages to syslog instead of stderr.
  • -o OPTION — the big one, the multiverse of options, here's everything it can be:
    • debug — enable debug output.
    • flock | no_flock — enable/disable flock. the default is no_flock.
    • modcaps=CAPLIST — modify the list of capabilities allowed; CAPLIST is a colon separated list of capabilities, each preceded by either + or -, e.g. '+sys_admin:-chown'. yes those quotes matter, no i will not be taking questions. 💀
    • log_level=LEVEL — print only log messages matching LEVEL or more severe. LEVEL is one of err, warn, info, or debug. the default is info.
    • posix_lock | no_posix_lock — enable/disable remote POSIX locks. the default is no_posix_lock.
    • readdirplus | no_readdirplus — enable/disable readdirplus. the default is readdirplus.
    • sandbox=namespace|chroot — sandbox mode:
      • namespace: create mount, pid, and net namespaces and pivot_root(2) into the shared directory.
      • chroot: chroot(2) into shared directory (use in containers). the default is "namespace".
    • source=PATH — share host directory tree located at PATH. this option is required. like, required required. you cannot skip it bestie. 🚨
    • timeout=TIMEOUT — I/O timeout in seconds. the default depends on the cache= option.
    • writeback | no_writeback — enable/disable writeback cache. the cache allows the FUSE client to buffer and merge write requests. the default is no_writeback.
    • xattr | no_xattr — enable/disable extended attributes (xattr) on files and directories. the default is no_xattr.
    • posix_acl | no_posix_acl — enable/disable posix acl support. Posix ACLs are disabled by default.
    • security_label | no_security_label — enable/disable security label support. Security labels are disabled by default. this will allow client to send a MAC label of file during file creation. typically this is expected to be SELinux security label. server will try to set that label on newly created file atomically wherever possible.
    • killpriv_v2 | no_killpriv_v2 — enable/disable FUSE_HANDLE_KILLPRIV_V2 support. KILLPRIV_V2 is enabled by default as long as the client supports it. enabling this option helps with performance in the write path. performance queen behavior. ⚡
  • --socket-path=PATH — listen on vhost-user UNIX domain socket at PATH.
  • --socket-group=GROUP — set the vhost-user UNIX domain socket gid to GROUP.
  • --fd=FDNUM — accept connections from vhost-user UNIX domain socket file descriptor FDNUM. the file descriptor must already be listening for connections. no takesies-backsies, it's gotta be ready. 🙈
  • --thread-pool-size=NUM — restrict the number of worker threads per request queue to NUM. the default is 0.
  • --cache=none|auto|always — select the desired trade-off between coherency and performance:
    • none forbids the FUSE client from caching to achieve best coherency at the cost of performance.
    • auto acts similar to NFS with a 1 second metadata cache timeout.
    • always sets a long cache lifetime at the expense of coherency. the default is auto.

to be continued, bestie… 💜

🌈 EXTENDED ATTRIBUTE (XATTR) MAPPING 🌈

okay bestie so here's the tea on xattrs 💅

by default, the names of the xattrs that the client uses just get passed straight through to the server's file system. no filter, no nothing. and that can be a whole problem when either:

  • something on the server is already using those xattr names (hi, selinux client/server confusion, we see you 🙈)
  • or virtiofsd is chilling in a container with restricted privileges and literally cannot touch some attributes

🎀 Mapping syntax 🎀

you can map xattr names using -o xattrmap=mapping, where the mapping string is just a series of rules, one after another.

the first matching rule terminates the mapping. so the rule set must include a terminating rule to catch any remaining attributes at the end. no cap, this is mandatory 🫶

each rule is made of a bunch of fields separated by a separator — and that separator is whatever the first non-white space character in the rule is. once you pick it, you use it for the whole entire rule. white space is allowed before and after each rule, so you can breathe. 🌸

using : as the separator, a rule looks like this:

:type:scope:key:prepend:

and scope is:

  • 'client' — match 'key' against a xattr name coming from the client, for setxattr/getxattr/removexattr
  • 'server' — match 'prepend' against a xattr name coming from the server, for listxattr
  • 'all' — use this to make a single rule where both the server and client matches get triggered at once

and type is one of these icons 👑:

  • 'prefix' — designed to prepend and strip a prefix; the modified attributes then get passed on to the client/server
  • 'ok' — causes the rule set to be terminated when a match is found, while letting matching xattrs through unchanged. it's meant both as a way to explicitly terminate the list of rules, and to let some xattrs skip the following rules
  • 'bad' — if a client tries to use a name matching 'key', it's denied using EPERM; when the server passes an attribute name matching 'prepend', it's hidden. in many ways it's used very much like 'ok', either as an explicit terminator or for special handling of certain patterns
  • 'unsupported' — if a client tries to use a name matching 'key', it's denied using ENOTSUP; when the server passes an attribute name matching 'prepend', it's hidden. again, in many ways it's used very much like 'ok', either as an explicit terminator or for special handling of certain patterns

key is a string tested as a prefix on an attribute name that originated on the client. it may be empty, in which case a 'client' rule will always match on client names.

prepend is a string tested as a prefix on an attribute name that originated on the server, and it's used as a new prefix. it may be empty, in which case a 'server' rule will always match on all names from the server.

e.g.:

:prefix:client:trusted.:user.virtiofs.:

will match 'trusted.' attributes in client calls and prefix them before passing them to the server.

:prefix:server::user.virtiofs.:

will strip 'user.virtiofs.' from all server replies.

:prefix:all:trusted.:user.virtiofs.:

combines the previous two cases into a single rule. iconic ✨

:ok:client:user.::

will allow get/set xattr for 'user.' xattrs and ignore the following rules.

:ok:server::security.:

will pass 'security.' xattrs in listxattr from the server and ignore the following rules.

:ok:all:::

will terminate the rule search, passing any remaining attributes in both directions.

:bad:server::security.:

would hide 'security.' xattrs in listxattr from the server.

there's also a simpler 'map' type that gives you a shorter syntax for the common case:

:map:key:prepend:

the 'map' type adds a number of separate rules to add prepend as a prefix to the matched key (or all attributes if key is empty). there may be at most one 'map' rule and it must be the last rule in the set. periodt.

📝 Note: when the 'security.capability' xattr is remapped, the daemon has to do extra work to remove it during many operations, which the host kernel normally does itself.

💜 Security considerations 💜

operating systems typically partition the xattr namespace using well defined name prefixes. each partition may have different access controls applied to it. for example, on Linux there are multiple partitions:

  • system.* — access varies depending on attribute & filesystem
  • security.* — only processes with CAP_SYS_ADMIN
  • trusted.* — only processes with CAP_SYS_ADMIN
  • user.* — any process granted by file permissions / ownership

while other OSes such as FreeBSD have different name prefixes and access control rules.

when you're remapping attributes on the host, it is important to make sure the remapping does not let a guest user evade the guest access control rules. this is the part where you sit up straight bestie 🫣

consider if trusted.* from the guest was remapped to user.virtiofs.trusted* in the host. an unprivileged user in a Linux guest has the ability to write to xattrs under user.*. so that user can evade the access control restriction on trusted.* by instead writing to user.virtiofs.trusted.*. yeah. that's a bypass. 💀

as noted above, the partitions used and the access controls applied will vary across guest OS, so it is not wise to try to predict what the guest OS will use.

the simplest way to avoid an insecure configuration is to remap all xattrs at once, to a given fixed prefix. this is shown in example (1) below.

if you're selectively mapping only a subset of xattr prefixes, then rules must be added to explicitly block direct access to the target of the remapping. that's example (2) below.

🦋 Mapping examples 🦋

  1. Prefix all attributes with 'user.virtiofs.'
-o xattrmap=":prefix:all::user.virtiofs.::bad:all:::"

this uses two rules, using : as the field separator; the first rule prefixes and strips 'user.virtiofs.', the second rule hides any non-prefixed attributes that the host set.

this is equivalent to the 'map' rule:

-o xattrmap=":map::user.virtiofs.:"
  1. Prefix 'trusted.' attributes, allow others through
"/prefix/all/trusted./user.virtiofs./
 /bad/server//trusted./
 /bad/client/user.virtiofs.//
 /ok/all///"

here there are four rules, using / as the field separator, and it also demonstrates that new lines can be included between rules. the first rule is the prefixing of 'trusted.' and stripping of 'user.virtiofs.'. the second rule hides unprefixed 'trusted.' attributes on the host. the third rule stops a guest from explicitly setting the 'user.virtiofs.' path directly, to prevent access control bypass on the target of the earlier prefix remapping. finally, the fourth rule lets all remaining attributes through.

this is equivalent to the 'map' rule:

-o xattrmap="/map/trusted./user.virtiofs./"
  1. Hide 'security.' attributes, and allow everything else
"/bad/all/security./security./
 /ok/all///'

the first rule combines what could be separate client and server rules into a single 'all' rule, matching 'security.' in either client arguments or lists returned from the host. this stops the client from seeing any 'security.' attributes on the server, and stops it setting any.

🔥 SELINUX SUPPORT 🔥

you can enable support for SELinux by running virtiofsd with the option -o security_label. but heads up: this will try to save the guest's security context in the xattr security.selinux on the host, and it might fail if the host's SELinux policy does not permit virtiofsd to do this operation. 😭

hence, it is preferred to remap the guest's "security.selinux" xattr to say "trusted.virtiofs.security.selinux" on the host.

-o xattrmap=:map:security.selinux:trusted.virtiofs.:

this will make sure that the guest's and the host's SELinux xattrs on the same file remain separate and don't interfere with each other. and it will allow both host and guest to implement their own separate SELinux policies. slay 🫶

setting a trusted xattr on the host requires CAP_SYS_ADMIN. so you'll need to add this capability to the daemon.

-o modcaps=+sys_admin
⚠️ giving CAP_SYS_ADMIN increases the risk on the system. now virtiofsd is more powerful, and if it gets compromised, it can do a lot of damage to the host system. so keep this trade-off in mind while making a decision. fr fr, don't skip this one.

✨ EXAMPLES ✨

export /var/lib/fs/vm001/ on vhost-user UNIX domain socket /var/run/vm001-vhost-fs.sock:

host# virtiofsd --socket-path=/var/run/vm001-vhost-fs.sock -o source=/var/lib/fs/vm001
host# qemu-system-x86_64 \
      -chardev socket,id=char0,path=/var/run/vm001-vhost-fs.sock \
      -device vhost-user-fs-pci,chardev=char0,tag=myfs \
      -object memory-backend-memfd,id=mem,size=4G,share=on \
      -numa node,memdev=mem \
      ...
guest# mount -t virtiofs myfs /mnt

👑 AUTHOR 👑

Stefan Hajnoczi <stefanha@redhat.com>, Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>

2025, The QEMU Project Developers

and that's the whole page bestie, we made it 🫶 this was version 7.2.18, dated Aug 15, 2025, from the VIRTIOFSD(1) manual — go forth and mount things responsibly 💖✨

📦 where this page comes from