Mounting Nextcloud AIO User Files as Read-Only with bindfs

When running Nextcloud AIO (All-in-One) via Docker, your user files live deep inside a Docker volume. If you need other services on the host — like a media server, a backup agent, or a file indexer — to access those files without risking accidental modifications, bindfs paired with an fstab entry is a clean and reliable solution.

The Problem

Nextcloud AIO stores user data in a Docker volume, typically located at:

/var/lib/docker/volumes/nextcloud_aio_nextcloud_data/_data/<username>/files/

Accessing this path directly from the host has two major drawbacks:

1. Ownership mismatch — files inside the container are owned by the www-data user (UID 33), which doesn't map to your host user.
2. No write protection — any process running on the host could accidentally modify or delete Nextcloud-managed files, leading to sync conflicts or data loss.

The Solution: bindfs

bindfs is a FUSE-based filesystem that creates a mirror of an existing directory with remapped ownership and permissions. Unlike a simple mount --bind, it lets you override the apparent owner, group, and permission bits on the fly.

Combined with an fstab entry, the mount is persistent across reboots and requires zero manual intervention.

Setup

1. Install bindfs

sudo apt install bindfs

2. Create the mount point

sudo mkdir -p /mnt/nextcloud-data

3. Add the fstab entry

Open /etc/fstab and add the following line:

bindfs#/var/lib/docker/volumes/nextcloud_aio_nextcloud_data/_data/<username>/files/  /mnt/nextcloud-data  fuse  ro,force-user=user,force-group=user,perms=0555  0  0

Replace <username> with your actual Nextcloud username.

4. Mount it

sudo mount /mnt/nextcloud-data

Or simply reboot — fstab takes care of it.

Breaking Down the Options

Why This Works Well

Ownership remapping is the key benefit here. Inside the Docker volume, Nextcloud's www-data user (UID 33) owns everything. On the host, your services likely run as a different user. With force-user and force-group, the user user can read every file without sudo or group hacking.

Read-only at the filesystem level means even root can't accidentally write through /mnt/nextcloud-data. Nextcloud remains the sole authority over its data. This is stronger than relying on Unix permissions alone.

No duplication — unlike rsync or copy-based approaches, bindfs is a live view of the actual data. No wasted disk space, no stale copies, no sync jobs to maintain.

Practical Use Cases

This setup is particularly useful when you want to:

• Serve media via Jellyfin, Plex, or Navidrome — point your media server at /mnt/nextcloud-data/Music or /mnt/nextcloud-data/Videos and let it index Nextcloud-managed files directly.
• Run read-only backups — tools like restic or borg can back up /mnt/nextcloud-data without any risk of modifying the source.
• Index files with a search engine — services like Meilisearch or Recoll can crawl the mount point safely.
• Share files over Samba or NFS — expose /mnt/nextcloud-data (or a subdirectory) as a read-only network share.

Things to Keep in Mind

• Docker must be running before the mount can succeed. If Docker starts after fstab is processed, the source path might not exist yet. You can fix this with a systemd mount unit that depends on docker.service, or by using nofail in the fstab options to prevent boot failures.
• Nextcloud file scans are unaffected — bindfs operates at the host level and doesn't touch the container's internal view.
• Performance overhead is negligible for typical file serving workloads. bindfs adds a thin FUSE layer, but for sequential reads (media streaming, backups), you won't notice it.
• New files uploaded through Nextcloud appear instantly at /mnt/nextcloud-data since it's a live mirror — no refresh or remount needed.

Adding nofail for Safety

If you want to prevent boot issues in case Docker isn't ready yet:

bindfs#/var/lib/docker/volumes/nextcloud_aio_nextcloud_data/_data/<username>/files/  /mnt/nextcloud-data  fuse  ro,nofail,force-user=user,force-group=user,perms=0555  0  0

The nofail option tells the system to continue booting even if this mount fails, which you can then retry manually or via a systemd timer.

Wrapping Up

A single fstab line gives you a safe, zero-maintenance, read-only window into your Nextcloud data. No copies, no cron jobs, no permission headaches. Your host services get the access they need, and Nextcloud stays in full control of its files.