How to Mount S3-Compatible Object Storage on Linux with rclone

To mount S3-compatible object storage on Linux with rclone, install rclone and FUSE, create a dedicated S3 remote with the endpoint and credentials, verify access to the bucket, and then mount it using rclone mount.

For more reliable writes, use the VFS cache—for example, with --vfs-cache-mode writes. For a persistent mount, use systemd rather than starting it manually or relying solely on --daemon.

Keep in mind that an S3 mount only emulates a file system. It is suitable for archives, media, and other relatively infrequently modified data, but is less suitable for databases, frequent random writes, and applications that require strict POSIX semantics.

If persistent file access is not required, using rclone sync or rclone copy is generally simpler and more reliable for backups and periodic data transfers.

Why Mount Object Storage as a File System?

Welcome!

S3-compatible Object Storage is well suited for backups, archives, media files, and large datasets. However, applications and administrators sometimes need more than individual commands such as upload, download, or sync.

They may want to open a regular Linux directory, navigate to it with cd, view its contents with ls, and work with remote objects much like files on a local disk.

This is exactly what rclone mount is for. Because it uses FUSE, it is not a stable solution and runs counter to the object storage model. However, it can be a practical approach for certain legacy systems and during transition periods.

This article explains how to install rclone, connect to S3-compatible storage through a custom endpoint, verify the connection, and manually mount a bucket using FUSE. We will then configure the VFS cache, access permissions, and automatic startup with systemd.

We will also discuss where the convenience of this approach ends.

An S3 mount may look like a standard file system, but underneath it remains object storage. This affects performance, rename operations, file writes, locking, and use cases.

Finally, we will examine when a persistent mount is genuinely useful and when it is better to avoid mounting altogether and use rclone sync instead.

How rclone Turns Object Storage into a Linux “Disk”

When you mount an S3 bucket using rclone, it can appear in the system as a standard mount point, such as /mnt/storage.

You can then run ls /mnt/storage, open a file in an application, or copy data to it using familiar Linux tools.

However, there is no physical disk behind this directory.

An additional layer sits between Linux and S3, translating file operations into requests to Object Storage.

To properly understand how rclone mount behaves, we first need to examine how this layer works.

Why S3 Cannot Be Mounted as a Regular File System

A conventional file system such as ext4 or XFS operates on a block device.

It has familiar entities and features:

• files;
• directories;
• inodes;
• access permissions;
• timestamps;
• operations for reading and writing individual blocks;
• renaming;
• file locking.

S3 works differently.

It does not provide a disk that Linux can simply mount using the mount command. Instead, it provides an HTTP API through which clients create, read, and delete objects.

In other words, the conventional architecture looks roughly like this:

For S3, it looks like this:

Therefore, a standard mount command such as mount /dev/sdb1 /mnt/data does not apply here: Object Storage simply has no /dev/sdb1 device.

To expose S3 as a Linux directory, an intermediary is needed to receive file system operations from the kernel and translate them into requests to the remote API.

This is exactly what the rclone + FUSE combination does.

What FUSE Does

FUSE stands for Filesystem in Userspace.

It is a Linux mechanism that allows a file system to be implemented as a regular user-space application rather than within the kernel.

From the system’s perspective, a file system appears to be mounted at /mnt/storage.

However, when an application performs an operation such as reading a file, the request is passed to a process rather than to a local disk. In our case, that process is rclone.

rclone then determines which operations to perform through the S3 API.

In simplified terms, the sequence looks like this:

The same process works in reverse.

If an application creates a file at the mount point, rclone must translate this operation into an object upload to S3.

FUSE is what makes this translation transparent to most regular applications.

The application does not need to know that the file is physically stored in Object Storage. It simply works with a path such as /mnt/storage/report.pdf.

How rclone Converts Object Keys into Familiar Paths

As in the previous article on the AWS CLI, it is important to remember that S3 does not have a true directory tree.

Suppose a bucket contains objects with the following keys:

documents/report.pdf

documents/contracts/2026.pdf

images/logo.png

To S3, these are simply three keys.

However, rclone can present them on Linux as:

In other words, the / character within an object key is interpreted as a directory separator.

This allows the ls command to display a familiar directory structure, even though the documents and contracts directories may not physically exist as separate objects.

This is particularly apparent with empty directories.

In a conventional file system, you can create a directory and leave it empty.

In S3, an empty folder typically has no meaning on its own. Some clients create a special zero-byte marker object to preserve the directory visually, but this is merely a client-side convention.

Therefore, the tree displayed by rclone is best understood as a file-system representation of the object key, rather than the actual internal structure of S3.

Why This Type of Mounting Remains a File System Emulation

This is the key idea behind everything we are doing.

After running rclone mount, the directory behaves much like a conventional file system, but that does not turn S3 into ext4.

rclone simply tries to adapt these two different models to each other.

Some operations therefore have to be emulated.

For example, on a conventional file system, renaming a file within the same partition can be a very inexpensive operation: only the metadata changes, while the data itself remains in place.

In S3, the name is effectively part of the object key.

Therefore, changing a path from old/report.pdf to new/report.pdf may require creating an object under the new key and deleting the old one.

For a large object, this entails a very different cost and latency.

A similar issue arises with applications that repeatedly open a file, modify specific sections, and save it again.

A conventional local disk is well suited to small-block random writes.

Object Storage is generally designed to work with entire objects.

To hide some of these differences, rclone uses a VFS layer and a local cache, which we will configure in detail later.

However, the fundamental characteristics of S3 cannot be eliminated entirely.

Therefore, rclone mount is best viewed as a convenient file system interface for object storage.

This approach can be very convenient for viewing documents, media, and archives, as well as for relatively sequential file operations.

However, a database, intensive random writes, or applications that depend on strict POSIX semantics may require a real file system.

Now that the S3 mount architecture and the role of FUSE are clear, it is worth briefly considering an alternative. rclone is not the only tool that can expose an S3 bucket as a Linux directory, so before moving on to the practical configuration, we will compare it with s3fs and examine how the two approaches differ.

How rclone mount differs from s3fs

rclone mount is not the only way to expose an S3 bucket as a Linux directory. Another common option is s3fs, which also uses FUSE and translates file operations into S3 API requests.

The tools have slightly different focuses. s3fs was designed specifically as a filesystem interface for S3 and supports many familiar POSIX attributes and operations, including permissions, UID/GID, symbolic links, and extended attributes. However, the limitations of object storage still apply. For example, S3 does not support standard atomic renames, hard links, or full coordination among multiple clients.

rclone mount, by contrast, places a strong emphasis on its VFS layer. The --vfs-cache-mode option lets you control how extensively the local cache is used, ranging from nearly direct access to the remote to read and write caching. This makes it possible to adapt rclone flexibly to applications that require a more conventional filesystem interface, although greater compatibility comes at the cost of local disk space and additional resource usage.

Therefore, neither tool can be universally described as more lightweight or faster than the other. The choice depends on the workload, the application’s requirements for file operations, and the cache settings. s3fs is worth considering as a more specialized option for mounting S3 storage, while rclone is a more versatile tool that, in addition to mounting, supports copy and sync operations and works with many other backends.

For the remainder of this guide, we will use rclone mount. It provides flexible access through the VFS cache, works well with S3-compatible storage, and can also perform copy, sync, and other operations. We can now move on to the practical steps: installing rclone, verifying FUSE, and preparing Linux for its first connection to S3-compatible storage.

Installing rclone and Checking FUSE

Required Components

The basic setup requires three components:

• a Linux system;
• rclone;
• FUSE.

rclone connects to the S3 API and translates file operations into requests to object storage.

FUSE handles another part of the setup: presenting the remote as a standard Linux directory.

In other words, they serve different purposes: rclone knows how to work with S3, while FUSE integrates this interaction into the system’s file hierarchy.

FUSE support is generally already available in modern Linux distributions. However, the user-space package may need to be installed separately.

For example, Ubuntu typically uses the fuse3 package.

How the Repository Package Differs from the Official rclone Installation

The easiest way to install rclone is to use the package from your distribution’s repository.

On Ubuntu, you can install it using APT.

The advantage of this approach is clear: the package is installed through the standard package management system, updated along with the rest of the system, and requires no separate maintenance.

However, there is one caveat.

The version of rclone available in the repository for a particular Ubuntu release may be older than the project’s latest release.

This is not always a problem. For basic operations such as copy, sync, and mount, even an older version is usually sufficient.

However, the version becomes important if you need the latest VFS options, fixes for a specific backend, or new S3 features.

There are therefore two main approaches:

1. Install rclone from the system repository.
2. Use the official rclone installation script.

For a general-purpose server guide, the first option is a better default because it is simpler and more predictable.

The official installation method is preferable if you need a more recent version.

Before using the installation script in production, however, it is advisable to review its contents and the project’s official documentation rather than blindly piping a remote script directly into a shell.

How to Check the rclone Version and FUSE Availability

After installation, first verify that rclone runs successfully.

To do this, run the rclone version command.

The output will show the client version, operating system, and architecture.

This is useful for more than just verifying the installation. If you later encounter an issue with a particular option, the rclone version will immediately tell you whether it is supported.

Next, check FUSE.

The simplest approach is to verify that the appropriate package is installed and that the fusermount3 utility is available.

For example, the fusermount3 –version command displays the version of the FUSE 3 user-space component.

You can also check whether the /dev/fuse device exists. If it does, the kernel provides a FUSE interface to user-space applications.

On a standard VPS, this is usually already configured.

However, the situation may be different inside some containers: /dev/fuse may be unavailable, and container policies may prohibit the use of FUSE. In such an environment, simply installing the package will not make rclone mount work.

This is an important distinction: rclone copy or rclone sync may work normally inside a container even when rclone mount does not, because mounting specifically requires access to FUSE.

Hands-on

On Ubuntu, you can install rclone and FUSE 3 as follows:

   sudo apt update
sudo apt install -y rclone fuse3

Then verify rclone: rclone version

Verify FUSE: fusermount3 –version

Check that the device exists: ls -l /dev/fuse

If rclone is installed, fusermount3 is available, and /dev/fuse exists, the system is ready for further configuration.

Command Summary

Linux is now ready for mounting, but rclone does not yet know which S3 storage service to connect to.

Next, we will create a separate remote, specify the provider’s endpoint, and save the credentials in the rclone configuration.

Adding S3-Compatible Storage to rclone

What Is a Remote in rclone?

A remote can be thought of as a connection profile.

It groups several settings under a single short name.

For example, instead of specifying the endpoint, Access Key, Secret Key, and region every time, you only need to create a remote named storage once:

This makes commands much shorter.

For example, listing buckets might look like this:

rclone lsd storage:

To work with a specific bucket:

rclone ls storage:my-bucket

In other words, the remote answers the question: How do I connect to this storage?

The part after the colon specifies which bucket or path within it to use.

This is particularly useful when managing multiple connections, because rclone can store configurations for different providers at the same time.

Parameters to Obtain from the Provider

For an S3-compatible remote, you will typically need the same basic information as when using the AWS CLI:

• Access Key ID;
• Secret Access Key;
• endpoint;
• region;
• and, in some cases, additional parameters specific to the service.

For example, the endpoint may look like this: https://s3.example-provider.com

The region may look like this: us-east-1

Alternatively, it may have a provider-specific name.

During setup, rclone will also prompt you to select an S3 provider.

The list includes Amazon, Ceph, MinIO, and other options, but for a third-party S3-compatible service, you will typically select an option such as Other.

This is important because the provider setting affects certain default values and backend behavior.

If the provider’s documentation specifies which option to select in rclone, it is best to follow those instructions.

How to Select S3 as the Storage Type and Specify a Custom Endpoint

Configuration is performed using the interactive rclone config command.

When launched, rclone displays the remote management menu.

To set up a new connection, select the option to create a new remote, give it a name such as storage, and then select s3 as the storage type.

rclone will then prompt you for each connection parameter.

The process is roughly as follows:

1. Create a new remote.
2. Name it storage.
3. Select s3 as the storage type.
4. Select the appropriate provider. For a generic S3-compatible service, choose Other.
5. Enter the Access Key ID.
6. Enter the Secret Access Key.
7. Specify the region.
8. Specify the custom endpoint.
9. Leave the remaining parameters at their default values unless the provider’s documentation specifies otherwise.

The key is not to guess any of the values.

If the endpoint or region is incorrect, the remote configuration will still be saved, but subsequent requests may fail with connection or signature errors.

Before configuring the remote, open the provider’s control panel or documentation and gather all the required parameters.

Where rclone Stores Its Configuration and Credentials

rclone stores remote settings in its own configuration file.

You can find the exact path by running rclone config file.

On Linux, this is typically a file in the user’s configuration directory, for example:

~/.config/rclone/rclone.conf

It may contain a section similar to the following:

   [storage]
type = s3
provider = Other
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
endpoint = https://s3.example-provider.com

The exact set of entries depends on the rclone version and the options selected.

It is important to understand that this file contains sensitive information.

rclone may hide or obfuscate some values in certain scenarios, but the configuration file should still be treated as secret.

You should not:

• Publish it anywhere;
• Add it to Git;
• Attach the entire file to tickets;
• Copy it to publicly accessible directories.

It is safer to check which configuration file rclone is currently using by running rclone config file rather than displaying the file’s contents.

Up to €20,000 in EU-Based IaaS Credits

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get

Why It Is Better to Create a Separate Remote for Each Storage Service

Technically, you can keep editing a single remote and changing its endpoint or credentials.

However, this quickly becomes inconvenient.

Suppose a single server uses two storage services:

backup-storage

media-storage

They have different endpoints, keys, and regions.

If they are configured as two separate remotes, the commands remain clear: backup-storage:backups and media-storage:images

This reduces the risk of accidentally sending data to the wrong provider or using the wrong credentials.

Hands-on: Creating an S3-Compatible Remote

Launch the configuration wizard: rclone config

Next, select the option to create a new remote: n) New remote

Enter a name: storage

Select S3 as the storage type: s3

If you are using a third-party S3-compatible service and its documentation does not specify otherwise, select Other as the provider.

Then enter the Access Key, Secret Key, region, and endpoint provided by the provider.

You can leave the additional parameters at their default values unless the service requires specific settings for addressing style, ACL, or other options.

After saving the configuration, verify that the remote has been added: rclone listremotes

The output should include: storage:

To view the path to the configuration file, run: rclone config file

Commands Used in This Chapter

The remote is now configured, but the existence of a configuration alone does not prove that the endpoint and credentials actually work.

Therefore, the next step is to run safe read-only commands and verify the connection before proceeding with mounting via FUSE.

Checking the Connection Before Mounting

Why You Should Start with Read Commands

For the initial check, it is best to use commands that do not modify the storage.

For example, rclone lsd and rclone ls.

These commands let you verify several things at once:

• the endpoint is reachable;
• the credentials are valid;
• the region does not conflict with the requests;
• the remote is actually being used;
• the user has at least basic read permissions.

If such a command completes successfully, you can proceed to FUSE.

If it fails, it is easier to troubleshoot the connection configuration rather than the mount options.

How to view buckets and bucket contents

To view the buckets available through the storage remote, use:

rclone lsd storage:

If the account has permission to list buckets, rclone will display output similar to the following:

   -1 2026-09-16 12:00:00        -1 backups
-1 2026-09-16 12:01:00        -1 media

An empty list does not necessarily indicate an error. The buckets may not have been created yet.

You can now view the contents of a specific bucket:

rclone ls storage:my-bucket

This command lists objects and their sizes.

For example:

   128 test.txt
54213 documents/report.pdf
2489143 backups/archive.tar.gz

If there are many files, rclone lsd storage:my-bucket may be more useful, as it displays only top-level directories and prefixes.

Another useful command is:

rclone about storage:

This command requests storage capacity information if the backend and provider support this operation.

For S3-compatible services, the about command may be unavailable or return limited information, so a lack of output does not necessarily indicate a problem.

How a Connection Error Differs from a Credentials Error

If rclone cannot connect to the endpoint at all, the error is typically related to the network or the service address.

Possible causes include:

• an incorrect endpoint;
• DNS resolution failure;
• the service being unavailable;
• a firewall blocking the connection;
• a TLS connection failure.

In this case, the problem occurs before the credentials can be properly validated.

If the server responds but rejects the credentials, the messages will be related to authentication.

For example, the cause may be an incorrect Access Key, Secret Key, or region.

The credentials may also be correct, but the associated permissions may be restricted. In that case, one request may succeed while another returns AccessDenied.

For example, a user may have access to storage:my-bucket but not have permission to list all buckets via storage:.

Therefore, when troubleshooting, it is best to check not only the remote root but also the specific bucket that should be accessible.

Quick Command Reference

If rclone can successfully read the bucket contents, the basic connection is working. You can now add the next layer—FUSE—and expose the bucket as a regular Linux directory.

Mounting the Bucket Manually via FUSE

At this point, the remote has already been verified, so you can proceed with rclone mount.

It is a good idea to mount the bucket manually at least once. This makes it easier to check the mount point, permissions, and file system behavior before configuring it to start through systemd.

Creating a Mount Point

First, you need a regular local directory.

For example: /mnt/storage

Create it with: sudo mkdir -p /mnt/storage

However, this immediately raises the issue of permissions.

If rclone runs as a regular user while the directory is owned by root, the process may not have the required permissions.

Therefore, it is best to assign ownership of the mount point to the user who will run rclone: sudo chown $USER:$USER /mnt/storage

The directory is now ready.

For now, it is empty and no different from a regular directory.

How rclone mount works

The basic command looks like this: rclone mount storage:my-bucket /mnt/storage

The first part specifies the source: storage:my-bucket

The second specifies the local mount point: /mnt/storage

Once started, rclone connects to the remote and uses FUSE to create a virtual file system.

The object documents/report.pdf is then available as /mnt/storage/documents/report.pdf

You can work with it using standard Linux commands, such as ls /mnt/storage or cat /mnt/storage/test.txt

To an application, it looks like a regular file path.

However, the data remains in Object Storage, while rclone translates read and write operations into S3 API requests.

Why the Process Must Remain Running

There is one important point: rclone mount is not a one-time command.

As long as the mount point exists, the rclone process that handles FUSE requests must remain running.

If you run:

rclone mount storage:my-bucket /mnt/storage

in a regular terminal, the command will remain in the foreground.

This is normal.

If you close the terminal or terminate the rclone process, the mount will disappear or become unavailable.

This is useful for testing because you can see that the process is currently running.

For continuous operation, we will later configure systemd to:

• Start the mount automatically;
• Restart rclone after a failure;
• Store logs;
• Bring the mount back up after the server reboots.

The --daemon option can also run rclone in the background, but systemd is generally more convenient and reliable for production use.

How to verify that the mount is available in the system

While rclone mount is running, open a second SSH session or terminal.

First, list the contents: ls -la /mnt/storage

If the bucket contains objects, they should appear here as files and directories.

To verify that the filesystem is mounted, run: mount | grep /mnt/storage or findmnt /mnt/storage

The latter is usually more convenient because it displays the source, mount point, and filesystem type in a compact format.

You can also try reading an existing file: cat /mnt/storage/test.txt

If the contents are displayed correctly, the entire chain is working:

   Linux
→ FUSE
→ rclone
→ S3 API
→ bucket

Once the manual check is complete, you can stop the mount by pressing Ctrl+C in the terminal where rclone is running.

Alternatively, unmount it separately: fusermount3 -u /mnt/storage

Command Quick Reference

At this point, the bucket already looks like a regular Linux directory. However, rclone is still primarily translating file operations into S3 requests, while some applications expect behavior much closer to that of a local disk.

To bridge this gap, we will configure the VFS cache next—one of the most important components for stable rclone mount operation.

Configuring the VFS Cache

Why rclone Needs a VFS Layer

VFS stands for Virtual File System.

In rclone, it is an additional layer between the application and remote storage that helps make a mount behave more like a conventional file system.

In simplified terms, the architecture looks like this:

Instead of immediately sending every small change to S3, rclone can temporarily work with a local copy of the file and then synchronize the result with Object Storage.

This is particularly useful for applications that expect to be able to:

• Reopen files;
• Modify parts of a file;
• Seek within a file;
• Write data non-sequentially;
• Work with temporary files.

In other words, the VFS cache does not change the nature of S3, but it helps smooth over the differences between object storage and a conventional file system.

What –vfs-cache-mode Changes

The key parameter here is --vfs-cache-mode.

It determines how extensively rclone should use the local disk as an intermediate cache.

The higher the mode, the more closely the file system behaves as applications expect, but the more local disk space, I/O operations, and additional complexity it requires.

This means you must always strike a balance between:

• Compatibility;
• Performance;
• Local disk usage;
• Data transfer speed to S3.

For basic read operations, the minimum mode may be sufficient.

Applications that write files extensively typically require a more full-featured cache mode.

Differences Between off, minimal, writes, and full

rclone has several main VFS cache modes. The table below summarizes them for convenience:

For a typical server-side mount, the following is often a good starting point: --vfs-cache-mode writes

This mode handles file writes properly without turning the local disk into a full cache of all content being read.

full is useful when applications repeatedly read the same data or frequently seek within large files.

However, this mode requires much closer monitoring of the cache size.

Where the Local Cache Is Stored

By default, rclone uses its own cache directory within the user’s environment.

You can view the exact path by running: rclone config paths

However, for a server configuration, it is often more convenient to specify the directory explicitly.

For example: /var/cache/rclone or /home/rclone/.cache/rclone

This offers several advantages.

You can immediately see:

• Where the cache is stored;
• Which partition it is on;
• How much space is available to it;
• Which permissions the systemd service requires.

You can specify the directory using the --cache-dir option.

For example: --cache-dir /var/cache/rclone

The directory must be accessible to the user account under which rclone runs.

How to Limit Cache Size and Retention

If left unmanaged, the VFS cache can consume a significant portion of the local disk.

For production environments, it is therefore best to configure limits from the outset.

The --vfs-cache-max-size option sets the maximum cache size.

For example: --vfs-cache-max-size 10G

The --vfs-cache-max-age option limits how long unused data is retained.

For example: --vfs-cache-max-age 24h

This means that old cached data is gradually removed.

This is especially important on smaller VPS instances.

If the system disk has only 20–40 GB of free space, an unmanaged VFS cache may eventually fill the partition and cause a range of other problems, from write errors to service failures.

Another consideration is that setting a size limit does not always mean that rclone will stop immediately at the exact specified threshold.

Cleanup runs periodically, and open or actively used files may continue to consume space.

It is therefore best to leave some headroom between --vfs-cache-max-size and the actual available disk space.

Why the Cache Uses Local Disk Space

A reasonable question sometimes arises: if the data is stored in Object Storage, why is a large local disk needed at all?

Because the VFS cache effectively uses it as an intermediate workspace.

For example, suppose an application writes an 8 GB file.

With --vfs-cache-mode writes, rclone may first store a significant portion of the file locally and then upload it to S3.

In other words, a mount does not completely eliminate the server’s need for local disk space.

It simply moves persistent data storage to Object Storage, while the local disk is used for caching, temporary data, and operations that cannot easily be performed directly through the S3 API.

This is particularly important when working with large files.

If you expect to work with 50–100 GB objects but the VPS has only 10 GB of free space, full mode or active writes through the cache can quickly run up against the disk space limit.

Hands-on: Enabling the VFS cache

Create a separate directory:

   sudo mkdir -p /var/cache/rclone
sudo chown $USER:$USER /var/cache/rclone

Now run rclone mount in writes mode:

   rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone

Add a size limit:

   rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G

And an age limit:

Full Control Over Your Kubernetes Infrastructure

Deploy production-ready Kubernetes with full control over nodes, storage, and networking on predictable-cost EU infrastructure with direct access to your resources.

Get

   rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G \
--vfs-cache-max-age 24h

In the next section, I’ll explain the main parameters and what they do.

Key VFS cache parameters

The mount is now better suited to applications that do more than just read files.

However, one important layer remains: access permissions. This is because the Linux user that sees /mnt/storage and the S3 service account that has access to the objects belong to two different authorization systems.

Understanding Access Permissions

When a bucket is mounted, two permission layers apply simultaneously:

1. Local Linux and FUSE permissions;
2. Permissions for the S3 storage itself.

These layers are only indirectly related.

You can configure /mnt/storage so that the directory is visible to all Linux users, but rclone will still be unable to delete an object if its S3 credentials do not include the DeleteObject permission.

Conversely, a service account may have full access to the bucket, while another Linux user may be unable to access the mount point due to FUSE restrictions.

Which Linux User the Mount Runs As

By default, rclone mount runs as the user who started the process.

For example, if the command is run by the ubuntu user, that user becomes the primary owner of the FUSE mount.

This affects access to:

• The mount point;
• The VFS cache;
• The rclone configuration;
• Files and directories within the mount.

Therefore, when configuring systemd later, it will be especially important to specify the user explicitly using User=.

It is generally best not to run rclone as root unless necessary. Instead, use a dedicated non-root user with minimal permissions and grant that user access only to the required directories.

What –uid, –gid, and –umask Control

Since S3 objects do not have actual POSIX permissions, rclone must emulate the owner and access mode for files displayed by Linux.

Options such as --uid, --gid, and --umask are used for this purpose.

More specifically:

• –uid specifies the user ID of the file owner.
• –gid specifies the group ID.
• –umask restricts the permissions exposed through the mount.

For example, a more restrictive umask: --umask 077 means that, in practice, only the owner will retain access.

A more permissive option: --umask 022 typically allows other users to read files, but not modify them.

It is important to understand that this is a local representation of permissions via FUSE, not a change to the S3 policy.

When –allow-other Is Needed

By default, a FUSE mount is usually accessible only to the user who created it.

If /mnt/storage needs to be accessible to, for example:

• Nginx;
• Docker;
• a media server;
• another systemd service;
• another Linux user,

you may need the following option: --allow-other

This option allows other system users to access the mount.

However, FUSE must usually be configured to allow this in /etc/fuse.conf.

The following line must be enabled in the configuration: user_allow_other

You can then start the mount, for example, as follows:

   rclone mount storage:my-bucket /mnt/storage \
--allow-other \
--vfs-cache-mode writes

However, you should not enable --allow-other automatically “just in case.”

It expands the scope of local access, so it is best used only when other users or services genuinely need access to the mount.

Why Linux Permissions Do Not Replace S3 Permissions

This is one of the most important points.

Suppose a file inside the mount has the following permissions: -rw-rw-rw-

This does not mean that any user can actually modify an object in S3.

The write operation is performed by the rclone process itself using its own credentials.

If the service account does not have PutObject permission, the write attempt will fail despite the local rw permissions.

Similarly, DeleteObject is required for deletion, GetObject for reading, and ListBucket for listing contents.

You can therefore think of these as two independent filters:

An operation must pass through both.

Local permissions determine whether an application can access the mount.

The S3 policy determines whether the backend permits the operation on the object.

What to Do If Another User or Service Cannot Access the Mount

A typical scenario is that an administrator runs ls /mnt/storage and sees the files, while Nginx or another service receives a Permission denied error.

In this case, check the following in order:

• The user account under which rclone is running;
• The user account under which the application is running;
• The owner of the mount point;
• The uid, gid, and umask values;
• Whether –allow-other is enabled;
• Whether user_allow_other is enabled in /etc/fuse.conf.

For example, you can check the directory owner by running ls -ld /mnt/storage and identify the user account under which a systemd service is running from its unit file.

If the local permissions are configured correctly but read or write operations still fail, check the S3 permissions for the remote.

Access Permission Options

Important: FUSE controls access to the local mount point, while the S3 policy governs actual object operations.

Starting rclone mount automatically with systemd

Manual mounting is working, the VFS cache is configured, and the access permissions are understood. However, rclone mount still depends on a specific shell session: the process must be started and monitored manually, then restarted after every server reboot.

This is impractical in production.

The next step is therefore to have systemd manage the process. The mount will then start automatically, run as the appropriate user, restart after failures, and write logs to the standard system journal.

Why –daemon Is Not Enough for Production

rclone provides the --daemon option, which runs the process in the background.

This is convenient for quick testing: the command does not tie up the terminal, and the mount continues to run.

However, this approach has limitations when used continuously on a server.

The --daemon option alone does not address several important requirements:

• It does not start the mount automatically after a reboot;
• It does not monitor the process status;
• It does not provide a centralized location for logs;
• It does not restart rclone after a failure;
• It does not define network dependencies;
• It does not specify which user the mount should run as.

In other words, --daemon simply runs the process in the background; it does not turn it into a fully managed service.

Therefore, systemd is more practical for production use.

Creating a Separate systemd Unit

systemd manages services through unit files.

For our mount, we can create a file such as /etc/systemd/system/rclone-storage.service

It will specify:

• When to start the service;
• Which user to run it as;
• Which command to execute;
• How to unmount the bucket;
• What to do if the service fails.

Example unit file:

   [Unit]
Description=Rclone S3 Mount
Wants=network-online.target
After=network-online.target
[Service]
Type=notify
User=ubuntu
ExecStart=/usr/bin/rclone mount storage:my-bucket /mnt/storage \
--config=/home/ubuntu/.config/rclone/rclone.conf \
--vfs-cache-mode=writes \
--cache-dir=/var/cache/rclone \
--vfs-cache-max-size=10G \
--vfs-cache-max-age=24h
ExecStop=/bin/fusermount3 -u /mnt/storage
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

Replace the User value and the configuration, mount point, and cache paths with the values appropriate for your system.

Now let’s look at why some of these lines are particularly important.

Why User, ExecStart, and ExecStop Matter

The User= parameter specifies which Linux user account rclone runs under.

For example: User=ubuntu

This affects several things:

• Access to rclone.conf;
• Access to /mnt/storage;
• Access to the VFS cache;
• Ownership of the FUSE mount.

If rclone was run manually as the ubuntu user, it makes sense to use the same user in systemd.

ExecStart= contains the mount command itself.

It is better to specify absolute paths here: /usr/bin/rclone, rather than simply: rclone

This is because systemd does not necessarily use the same environment and PATH as an interactive shell session.

The same applies to the configuration. It is best to specify it explicitly:

--config=/home/ubuntu/.config/rclone/rclone.conf

This ensures that the service does not depend on the HOME value that systemd assigns to the process.

ExecStop= is required for a clean unmount:

ExecStop=/bin/fusermount3 -u /mnt/storage

If the process is simply terminated without being properly unmounted, the mount point may remain in an inconsistent state until FUSE cleans it up.

This is why an explicit ExecStop makes service shutdown more predictable.

How to Wait for the Network Before Starting

This raises another question: what happens if systemd starts rclone before the server has a working network connection?

This is critical for a remote S3 mount because rclone cannot connect to the endpoint without network access.

For this reason, it is useful to include the following directives in the [Unit] section:

   Wants=network-online.target
After=network-online.target
After= defines the startup order: rclone must start after network-online.target has been reached.
Wants= adds the corresponding dependency.

This does not provide an absolute guarantee that the specific S3 endpoint will be available that very millisecond. However, systemd will at least not deliberately start the remote mount before the network is ready.

If the provider or DNS is temporarily unavailable, subsequent service restarts provide additional reliability.

How to Automatically Restart a Mount After a Failure

Even with a stable network, a remote mount may temporarily lose its connection.

For example:

• the endpoint becomes unavailable;
• a network failure occurs;
• the rclone process exits with an error;
• the FUSE mount stops unexpectedly.

To prevent systemd from leaving the service inactive, add:

   Restart=on-failure
RestartSec=5

Restart=on-failure means that systemd will attempt to restart the process if it exits abnormally.

RestartSec=5 adds a short delay between restart attempts.

This is better than restarting immediately and indefinitely: if the problem is external—for example, if the endpoint is temporarily unavailable—the service will not enter a tight restart loop.

A normal manual systemctl stop rclone-storage command should not be treated as a failure, so on-failure is more appropriate here than the unconditional always setting.

Where to View Logs

When rclone runs under systemd, you no longer need a separate terminal to display its output.

The main messages are written to the systemd journal.

To view the current status, run:

sudo systemctl status rclone-storage

This shows:

• Whether the service is running;
• The process PID;
• The latest messages;
• The cause of the most recent failure, if any.

To view the detailed log, run:

sudo journalctl -u rclone-storage

To monitor events in real time, run:

sudo journalctl -u rclone-storage -f

This is particularly useful when debugging the mount: you can access /mnt/storage from another terminal while monitoring any errors reported by rclone.

If the service fails to start, first check systemctl status and journalctl before making further changes to the unit file.

Hands-on: Creating and Starting a systemd Service

Create a unit file:

sudo nano /etc/systemd/system/rclone-storage.service

Add the following configuration:

   [Unit]
Description=Rclone S3 Mount
Wants=network-online.target
After=network-online.target
[Service]
Type=notify
User=ubuntu
ExecStart=/usr/bin/rclone mount storage:my-bucket /mnt/storage \
--config=/home/ubuntu/.config/rclone/rclone.conf \
--vfs-cache-mode=writes \
--cache-dir=/var/cache/rclone \
--vfs-cache-max-size=10G \
--vfs-cache-max-age=24h
ExecStop=/bin/fusermount3 -u /mnt/storage
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

After saving the file, reload the systemd configuration:

sudo systemctl daemon-reload

Now enable the service to start automatically and start it immediately:

sudo systemctl enable --now rclone-storage

Check the service status:

sudo systemctl status rclone-storage

Then verify that the mount is actually present:

findmnt /mnt/storage

View its contents:

ls -la /mnt/storage

To view the logs:

sudo journalctl -u rclone-storage

To follow the logs in real time:

sudo journalctl -u rclone-storage -f

Commands from This Chapter

The mount no longer depends on an active SSH session and can start automatically with the server.

Limitations of S3 Mounts

Once configured with systemd, the mount behaves almost like a full-fledged network drive: the directory appears automatically, applications see standard file paths, and rclone abstracts away most interactions with the S3 API.

However, it is important not to lose sight of the underlying architecture.

The storage mounted at /mnt/storage is still Object Storage, not ext4, XFS, or NFS. As a result, operations that are virtually cost-free on a conventional file system may require additional requests, object copying, or data re-uploading in S3.

These differences determine which use cases are well suited to rclone mount and where it becomes a hindrance.

Why Rename and Move Operations Can Be Expensive

In a conventional file system, renaming a file often involves only updating its metadata.

If a 20 GB file is renamed within the same partition, the 20 GB of data itself is typically not copied.

In S3, an object’s name is its key.

Therefore, changing a path such as archive/old.tar.gz to archive/new.tar.gz cannot always be performed as a simple rename operation.

On the backend, this operation may effectively involve creating an object with a new key, copying the data to it, and then deleting the old object.

For a single small file, the difference is barely noticeable.

However, if an application moves large files in bulk or renames entire “directories,” the operation can become significantly more expensive in terms of time, data transfer, and the number of S3 requests.

It is especially important to remember that a directory in S3 is essentially a shared key prefix. As a result, renaming a directory containing thousands of objects may require processing each object individually.

Why Small-Block Writes Behave Differently Than on a Regular Disk

A local file system is well suited to modifying individual sections of a file.

An application can open a large file, seek to the required offset, and modify a few kilobytes without having to rewrite the entire file.

Object Storage handles objects differently.

The S3 API is primarily designed for uploading, retrieving, and deleting objects rather than modifying individual disk blocks at arbitrary locations.

Therefore, when an application writes through rclone mount, rclone must adapt the file system model to the object storage model.

This is where the VFS cache helps: changes can be made temporarily on the local disk, and the final state can then be uploaded to S3.

However, this does not change the fundamental constraint. Under the hood, there is still no remote block device to which a few kilobytes can be written inexpensively at an arbitrary location.

As a result, applications that perform many small partial writes generally work less effectively on an S3 mount than on a true file system.

Why Random Access and Frequent File Changes Can Be Slower

The situation is similar for read operations.

High-Performance Virtual Machines

Deploy in seconds with full root access, reserved resources, built-in high availability, and predictable monthly pricing.

Get

Sequentially reading a large object fits the Object Storage model well: rclone retrieves the data over the network and passes it to the application.

However, if an application constantly jumps between different parts of a file, frequently opens and closes it, or modifies its contents in small chunks, the following factors become more significant:

• Network latency;
• VFS cache;
• Number of API requests;
• Local disk;
• File size.

The --vfs-cache-mode full mode can significantly improve performance in this scenario because some of the data is cached locally.

However, the mount then depends not only on S3 performance but also on the size and speed of the local cache.

This creates a trade-off: the more closely we try to make S3 behave like a conventional disk, the more local resources rclone requires for this emulation.

Therefore, an S3 mount is particularly well suited to data that changes relatively infrequently and is usually read in its entirety.

How File Locking Behaves

Some applications use file locks to prevent multiple processes from modifying the same file simultaneously.

On a standard POSIX file system, this is part of the expected operating model.

S3 has no built-in equivalent.

rclone can provide some of the expected behavior through its VFS layer, but this does not turn remote Object Storage into a distributed file system with full POSIX locking support.

Relying on such locks is especially risky when the same bucket is accessed simultaneously through:

• Multiple independent rclone mounts;
• AWS CLI;
• An application using the S3 API;
• The provider’s control panel.

One client may simply be unaware of a local lock created by another client.

Therefore, applications that critically rely on strict file locking and consistent concurrent access should be hosted on storage specifically designed for this type of workload.

Why You Should Avoid Putting Databases on an S3 Mount

A database is an almost perfect example of a workload that is poorly suited to the object storage model.

A DBMS expects very specific behavior from the file system:

• Fast random reads and writes;
• Frequent modifications to small portions of files;
• Reliable fsync;
• Predictable latency;
• Correct locking behavior;
• Strict file operation semantics.

An S3 mount cannot reliably turn Object Storage into this kind of block storage.

A VFS cache can mask some of these differences, but an additional layer involving the network and API still remains between the DBMS and the underlying object.

PostgreSQL, MySQL, SQLite, and other actively modified databases are therefore better stored on local or network-based block or file storage that meets their requirements.

Object Storage is, however, an excellent choice for another stage—for example, storing database dumps and backups.

This brings us to an important question: if the data does not need to be accessible as a permanently mounted directory, perhaps a mount is not the best tool at all.

When to Use rclone sync Instead of mount

When mount is genuinely useful

Rclone mount is a good fit when an application requires a standard file system path.

For example, an application may expect to read data from /mnt/storage/media but lack native support for the S3 API.

In this case, mount acts as an adapter between the application and Object Storage.

Good candidates include:

• Media libraries;
• Document archives;
• Image directories;
• Primarily read-only data;
• Large files that are rarely modified;
• Administrative browsing of remote storage contents.

In other words, mount is especially useful when you need remote objects to remain continuously visible as files.

When sync Is More Reliable and Simpler

If a persistent mount point is not required, rclone sync is often much simpler.

With sync, there is no continuously running FUSE process, no need to maintain a mount after a network outage, and usually no need for a large VFS cache.

The workflow is more straightforward: there is a source, there is a destination, and rclone synchronizes them at a specified time.

For example, you can use a systemd timer or cron to upload a directory to Object Storage once an hour.

Once the command completes, the local application continues to use the regular file system and does not depend on S3 availability in any way.

This makes sync particularly convenient when Object Storage is used as a remote copy rather than as an active file system.

Why Backups and Archives Are Often Better Synchronized

A persistent mount is generally unnecessary for backups.

If a backup is created locally as backup.tar.gz, it is easier to upload it to S3 with rclone copy once it is complete, or synchronize the directory with rclone sync.

This allows the process to be clearly divided into stages: first, a valid backup is created locally; then, the completed file is uploaded to remote storage.

This is often more reliable than having the backup software work directly over a FUSE mount.

The same applies to archives.

If files are created locally and then simply need to be transferred to Object Storage for long-term storage, a mount offers little benefit.

Instead, it adds extra dependencies: FUSE, a systemd service, VFS cache, and a persistent connection.

When Continuous File Access Is Required and When Periodic Transfers Are Sufficient

The choice comes down to one question: Does the application need to continuously see the remote data as part of its file system?

If so, using a mount may be justified.

If the requirement is to “upload new files to S3 every N minutes,” using sync is a much more natural choice.

The same applies in the opposite direction. If a local server only needs an up-to-date copy of a remote directory at regular intervals, you can sync S3 → local disk and then work with a standard file system.

This way, the application does not depend on network latency for every open() or read() call.

Which Option to Choose

So which option should you choose? The following table will help you decide:

Therefore, mount and sync are not direct competitors. The former provides a persistent filesystem interface, while the latter transfers state between two storage systems.

Making the right choice in advance can help you avoid most performance issues and unexpected S3 mount behavior.

The final step is to bring all the configured components together and perform a final check, from access to the remote to a persistent mount managed by systemd.

Testing the Complete Setup

All major components have already been configured individually: the remote connects to the S3-compatible endpoint, FUSE exposes the bucket as a Linux directory, the VFS cache bridges the differences between the file and object storage models, and systemd ensures continuous operation.

It is now useful to test the entire chain end to end. This helps ensure that no issues are hidden at the integration points between components.

For these examples, we will continue to use the storage remote, the my-bucket bucket, and the /mnt/storage mount point.

First, test rclone itself without involving FUSE. The remote should appear in the configuration, and the bucket contents should be accessible directly through the S3 API.

If these commands work, the endpoint, credentials, and basic access permissions are configured correctly. You can now proceed to the local side and test a manual mount.

Create the mount point if it does not already exist and assign ownership to the user who runs rclone. Then start the mount with the same VFS cache settings that you plan to use permanently.

   sudo mkdir -p /mnt/storage
sudo chown $USER:$USER /mnt/storage

   rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G \
--vfs-cache-max-age 24h

Because rclone remains in the foreground, it is more convenient to perform the remaining checks in a second SSH session.

The final command is particularly useful because it verifies the result without going through FUSE. If rclone-test.txt appears when listing the remote, the file has actually been uploaded to Object Storage rather than existing only in the local representation of the mount.

With the VFS cache enabled, you can also check the cache directory:

du -sh /var/cache/rclone

Keep in mind that the contents of the VFS cache change dynamically. After a successful upload, rclone may remove data that is no longer needed, so the absence of the test file from the cache does not mean that VFS is not working.

After testing, the manual mount is no longer needed. Stop it by pressing Ctrl+C in the terminal running rclone, or unmount it from the second session:

fusermount3 -u /mnt/storage

The final part of the test is to start the same mount through the previously created systemd unit rather than manually.

If the service is active, findmnt shows /mnt/storage, and the previously created file is still readable, the entire setup is working correctly:

To complete the automatic startup test, reboot the server and run the following commands again after reconnecting:

   sudo systemctl status rclone-storage
findmnt /mnt/storage
ls -la /mnt/storage

If the mount appears without starting rclone manually, the systemd configuration survives a reboot and is ready for continuous use.

After testing, you can delete the test object with a standard file command:

rm /mnt/storage/rclone-test.txt

Alternatively, delete it directly through rclone:

rclone deletefile storage:my-bucket/rclone-test.txt

This completes the technical setup. The final production considerations are to protect rclone.conf and the credentials, restrict the service account permissions, monitor the VFS cache size, and avoid using an S3 mount in scenarios where the application requires a full POSIX file system.

How to Use rclone mount Safely in Production

Do Not Store Configurations Containing Credentials in Publicly Accessible Locations

The rclone.conf file must be treated as sensitive.

Even if some values in the file appear obfuscated or are not readable as plain-text passwords, this is no reason to treat the configuration as a harmless text file.

It may contain:

• Access Key;
• Secret Key;
• Endpoint;
• Remote parameters;
• Additional connection details.

Therefore, the configuration should not be placed in a shared project directory, added to Git, or copied into publicly available instructions.

When using systemd, it is best to store the configuration in a separate user directory and explicitly specify its path using –config.

For example:

/home/ubuntu/.config/rclone/rclone.conf

The file itself should preferably be accessible only to its owner:

chmod 600 ~/.config/rclone/rclone.conf

If rclone runs under a dedicated system user, the configuration file must be owned by that user.

This ensures that access to the mount does not automatically grant access to the credentials used to operate it.

Restrict permissions for a dedicated service account

The next layer of protection is provided by Object Storage.

For an rclone mount, it is best to create a dedicated service account and grant it only the permissions it actually needs.

For example, if the directory is used only to read media files, the service account may not need PutObject or DeleteObject permissions.

If the mount must support file uploads but deletion is undesirable, write access can be granted without delete permission.

This is particularly important because a local command such as rm in /mnt/storage is ultimately translated into an S3 operation.

If the credentials include DeleteObject permission, the object will also be deleted from Object Storage.

Without this permission, the S3 API provides an additional safeguard.

Therefore, a production remote should follow the principle of least privilege: one service, one service account, and one specific set of permissions.

Control the VFS cache size

The VFS cache makes a mount significantly easier to use, but it also introduces a new local point of risk.

If the cache size is not controlled, it can gradually consume a significant portion of the system disk.

This is particularly problematic on a small VPS: a full partition can affect not only rclone but also the systemd journal, databases, Docker, and other services.

It is therefore best to set options such as --vfs-cache-max-size and --vfs-cache-max-age from the outset rather than waiting until the disk fills up for the first time.

For example:

--vfs-cache-max-size 10G

--vfs-cache-max-age 24h

The limit should be based not on the bucket size, but on the available space on the local partition and the nature of the workload.

If the application regularly works with files of 20–30 GB, a 5 GB cache may be too small even with a very large Object Storage capacity.

Disk usage can be monitored using standard Linux tools, such as df -h and du -sh /var/cache/rclone.

Monitor logs and reconnections

Remote storage depends on the network, DNS, and the availability of the S3 endpoint itself.

Therefore, brief connection errors cannot be completely ruled out in production.

What matters is that the service recovers from them correctly and that the administrator can determine what happened.

To accomplish this, we have already added the following to systemd: Restart=on-failure and RestartSec=5

All that remains is to check the logs periodically.

Run systemctl status rclone-storage for a quick status check; a more detailed history is available through journalctl -u rclone-storage.

Pay particular attention to recurring instances of the following:

• Authorization errors;
• Endpoint issues;
• Timeouts;
• FUSE messages;
• Cache full errors;
• Service restart loops.

A single network timeout and dozens of restarts within an hour are entirely different situations.

In this case, systemd is useful not only for starting the service automatically, but also as a convenient way to monitor the mount status.

Do Not Use an S3 Mount When a True POSIX File System Is Required

The final rule is perhaps the most important.

Even a well-configured rclone mount does not turn Object Storage into ext4, XFS, or NFS.

If an application critically depends on:

• Strict file locking;
• Reliable fsync behavior;
• Extremely low latency;
• Frequent random writes;
• Modifying small blocks within large files;
• Complex POSIX semantics,

It is best to choose suitable block or file storage from the outset.

Do not try to compensate for an architectural mismatch with increasingly aggressive VFS cache settings.

rclone mount is a good choice when a convenient file system interface for object storage is needed.

But when an application genuinely requires a real disk, it is better to provide one.

Conclusion

Rclone mount lets you present S3-compatible Object Storage as a regular Linux directory and work with remote objects using familiar file paths.

In this article, we configured the entire setup: installed rclone and FUSE, created an S3-compatible remote with a custom endpoint, verified the connection, mounted the bucket, added a VFS cache, configured permissions, and set up automatic startup with systemd.

However, mounting S3 does not turn it into a full-fledged POSIX file system. For backups, archives, and periodic data transfers, it is often easier to use rclone sync or rclone copy and reserve mount for scenarios that truly require persistent file access.

With these limitations in mind, proper VFS cache management, and no unnecessary permissions granted to the remote, rclone provides a convenient and predictable bridge between Linux and S3-compatible Object Storage.

FAQ

Can I use rclone mount without the VFS cache?

Yes, but compatibility with standard file operations will be limited. Without the VFS cache, rclone does not handle random writes, reopening files, and certain other use cases as well. For applications that write data through the mount, --vfs-cache-mode writes is generally a sensible starting point.

Why is a file visible through rclone but inaccessible to another Linux user?

The issue is usually at the FUSE layer rather than the S3 layer. By default, a mount is restricted to the user who created it. If other users or services need access, you may need to use --allow-other and enable user_allow_other in /etc/fuse.conf.

The S3 service account’s permissions must also be considered separately: local Linux permissions and access to objects in the storage system are two distinct layers.

Can I store a database directly on S3 using rclone mount?

This approach is best avoided for actively running PostgreSQL, MySQL, SQLite, and similar database systems. S3 remains object storage and does not provide the same random-write, fsync, locking, and low-latency semantics that a database expects from a conventional file system.

Object Storage is much better suited to storing database dumps and backups.

Which should you use for backups: rclone mount or rclone sync?

If a backup is created locally first and then needs to be uploaded to Object Storage, it is usually simpler to use rclone sync or rclone copy.

rclone mount makes sense when an application genuinely needs a file system path that is continuously available. For periodic transfers of completed files, FUSE, the VFS cache, and an always-on service are usually unnecessary.

Why can the VFS cache use more space than specified by –vfs-cache-max-size?

The limit is not an immediate hard cap. rclone checks the cache periodically, and open files cannot simply be removed from it while they are in use. As a result, the actual cache size may temporarily exceed the configured value. This is why you should leave additional free space on the local volume.

What happens to the mount after the server restarts?

If you run rclone mount manually, you will need to run it again after a restart.

For continuous operation, it is more convenient to let systemd manage the process. The service can automatically start rclone when the system boots, monitor the process, and restart it if it fails.

Why do changes in S3 sometimes not appear immediately in the mounted directory?

rclone caches directory information to avoid calling the remote API for every file operation. As a result, a change made directly through the provider’s control panel, another rclone instance, or a third-party S3 client may not appear in the mount immediately.

The refresh time depends on the directory cache and the specific backend’s ability to detect external changes.

Can the same VFS cache be used for multiple rclone mounts?

If multiple rclone instances access overlapping remotes and use the VFS cache, it is best not to share a cache directory between them. The rclone documentation warns that doing so could potentially lead to data corruption. For separate mounts, it is safer to specify different cache directories using --cache-dir.

Sources

1. rclone Documentation — rclone mount
2. rclone Documentation — Amazon S3 Storage Providers
3. rclone Documentation — General Documentation
4. libfuse — FUSE API Documentation