/rclone_serve_nfs

title: "rclone serve nfs"
description: "Serve the remote as an NFS mount"
status: Experimental
versionIntroduced: v1.65
# autogenerated - DO NOT EDIT, instead edit the source code in cmd/serve/nfs/ and as part of making a release run "make commanddocs"

> **Official documentation:** [https://rclone.org/commands/rclone_serve_nfs/](https://rclone.org/commands/rclone_serve_nfs/)

rclone serve nfs

Serve the remote as an NFS mount

Synopsis

Create an NFS server that serves the given remote over the network.

This implements an NFSv3 server to serve any rclone remote via NFS.

The primary purpose for this command is to enable the [mount command](/commands/rclone_mount/) on recent macOS versions where installing FUSE is very cumbersome.

This server does not implement any authentication so any client will be able to access the data. To limit access, you can use `serve nfs` on the loopback address or rely on secure tunnels (such as SSH) or use firewalling.

For this reason, by default, a random TCP port is chosen and the loopback interface is used for the listening address by default; meaning that it is only available to the local machine. If you want other machines to access the NFS mount over local network, you need to specify the listening address and port using the `--addr` flag.

Modifying files through the NFS protocol requires VFS caching. Usually you will need to specify `--vfs-cache-mode` in order to be able to write to the mountpoint (`full` is recommended). If you don't specify VFS cache mode, the mount will be read-only.

`--nfs-cache-type` controls the type of the NFS handle cache. By default this is `memory` where new handles will be randomly allocated when needed. These are stored in memory. If the server is restarted the handle cache will be lost and connected NFS clients will get stale handle errors.

`--nfs-cache-type disk` uses an on disk NFS handle cache. Rclone hashes the path of the object and stores it in a file named after the hash. These hashes are stored on disk the directory controlled by `--cache-dir` or the exact directory may be specified with `--nfs-cache-dir`. Using this means that the NFS server can be restarted at will without affecting the connected clients.

`--nfs-cache-type symlink` is similar to `--nfs-cache-type disk` in that it uses an on disk cache, but the cache entries are held as symlinks. Rclone will use the handle of the underlying file as the NFS handle which improves performance. This sort of cache can't be backed up and restored as the underlying handles will change. This is Linux only. It requires running rclone as root or with `CAP_DAC_READ_SEARCH`. You can run rclone with this extra permission by doing this to the rclone binary `sudo setcap cap_dac_read_search+ep /path/to/rclone`.

`--nfs-cache-handle-limit` controls the maximum number of cached NFS handles stored by the caching handler. This should not be set too low or you may experience errors when trying to access files. The default is `1000000`, but consider lowering this limit if the server's system resource usage causes problems. This is only used by the `memory` type cache.

To serve NFS over the network use following command:

rclone serve nfs remote: --addr 0.0.0.0:$PORT --vfs-cache-mode=full

This specifies a port that can be used in the mount command. To mount the server under Linux/macOS, use the following command:

mount -t nfs -o port=$PORT,mountport=$PORT,tcp $HOSTNAME:/ path/to/mountpoint

Where `$PORT` is the same port number used in the `serve nfs` command and `$HOSTNAME` is the network address of the machine that `serve nfs` was run on.

If `--vfs-metadata-extension` is in use then for the `--nfs-cache-type disk` and `--nfs-cache-type cache` the metadata files will have the file handle of their parent file suffixed with `0x00, 0x00, 0x00, 0x01`. This means they can be looked up directly from the parent file handle is desired.

This command is only available on Unix platforms.

VFS - Virtual File System

This command uses the VFS layer. This adapts the cloud storage objects that rclone uses into something which looks much more like a disk filing system.

Cloud storage objects have lots of properties which aren't like disk files - you can't extend them or write to the middle of them, so the VFS layer has to deal with that. Because there is no one right way of doing this there are various options explained below.

The VFS layer also implements a directory cache - this caches info about files and directories (but not the data) in memory.

VFS Directory Cache

Using the `--dir-cache-time` flag, you can control how long a directory should be considered up to date and not refreshed from the backend. Changes made through the VFS will appear immediately or invalidate the cache.

    --dir-cache-time duration   Time to cache directory entries for (default 5m0s)
    --poll-interval duration    Time to wait between polling for changes. Must be smaller than dir-cache-time. Only on supported remotes. Set to 0 to disable (default 1m0s)

However, changes made directly on the cloud storage by the web interface or a different copy of rclone will only be picked up once the directory cache expires if the backend configured does not support polling for changes. If the backend supports polling, changes will be picked up within the polling interval.

You can send a `SIGHUP` signal to rclone for it to flush all directory caches, regardless of how old they are. Assuming only one rclone instance is running, you can reset the cache like this:

kill -SIGHUP $(pidof rclone)

If you configure rclone with a [remote control](/rc) then you can use rclone rc to flush the whole directory cache:

rclone rc vfs/forget

Or individual files or directories:

rclone rc vfs/forget file=path/to/file dir=path/to/dir

VFS File Buffering

The `--buffer-size` flag determines the amount of memory, that will be used to buf