Connecting an Older Synology NAS to Nextcloud AIO on a ZimaBoard (via a Host-Level CIFS Mount)

Insight & Feedback
1

Why not just use Nextcloud’s built-in SMB external storage?

Nextcloud’s External Storage app lets you add an SMB/CIFS share directly through the web UI. That’s the obvious first choice, and it works fine for casual use. But if you’re dealing with:

  • An older NAS (in my case a Synology DS1513+, several generations old)

  • Large libraries (tens of thousands of files)

  • Heavy operations like generating previews for an entire photo library at once

…you may run into intermittent failures. Nextcloud AIO’s SMB client (libsmbclient-php, running inside the container) handles SMB3 encryption negotiation directly at the PHP level. Older Synology Samba stacks don’t always negotiate this consistently under load, especially when many connections open in quick succession. Symptoms include:

  • Encryption required and server doesn't support SMB3 encryption - failing connect

  • ConnectionRefusedException

  • Storage with mount id X is not available

These errors are intermittent — sometimes the connection works fine, sometimes it doesn’t, depending on server load. They’re annoying to debug because they don’t reproduce consistently.

The fix: mount at the host level instead

Instead of letting Nextcloud’s PHP layer manage the SMB connection, let the Linux kernel on your ZimaBoard (or any Docker host) handle it via a proper cifs mount. The kernel’s CIFS client is far more mature and battle-tested than a PHP wrapper library, and it handles reconnection and protocol negotiation more gracefully.

The flow becomes:

  1. Host mounts the Synology share via systemd.mount (survives reboots, and — if your host OS is immutable, like ZimaOS — survives OS updates too, since it lives in /etc/systemd/system rather than /etc/fstab on a read-only root).

  2. Nextcloud AIO’s NEXTCLOUD_MOUNT environment variable exposes that host path inside the Nextcloud container at the identical path.

  3. You add it in Nextcloud as External Storage → Local, not SMB/CIFS — because as far as the container is concerned, it’s just a local directory.

Step-by-step

1. Store your NAS credentials securely

sudo mkdir -p /etc/samba/credentials
sudo tee /etc/samba/credentials/my-nas << 'EOF'
username=your_nas_username
password=your_nas_password
EOF
sudo chmod 600 /etc/samba/credentials/my-nas

2. Create the mount point (on a writable path)

If your host OS has an immutable root filesystem (ZimaOS, some other appliance-style Linux distros), /mnt may not be writable. Find a writable data partition instead — on ZimaOS that’s typically under /media/ZIMASSD or wherever your data volume lives.

sudo mkdir -p /media/ZIMASSD/nc-synology-mount

3. Find the container’s user/group ID

Nextcloud’s web server runs as www-data inside the container, which is usually uid/gid 33 — but verify rather than assume:

sudo docker exec nextcloud-aio-nextcloud id www-data

4. Create a systemd mount unit

The unit filename must match the mount path, with / replaced by - and escaped as \x2d for any literal dashes in your directory names. Easiest to let systemd-escape do this for you:

systemd-escape -p --suffix=mount /media/ZIMASSD/nc-synology-mount

Then create the unit (adjust the What= path to your actual share):

sudo tee /etc/systemd/system/media-ZIMASSD-nc\x2dsynology\x2dmount.mount << 'EOF'
[Unit]
Description=NAS mount for Nextcloud
After=network-online.target
Wants=network-online.target

[Mount]
What=//NAS_IP_ADDRESS/your_share
Where=/media/ZIMASSD/nc-synology-mount
Type=cifs
Options=credentials=/etc/samba/credentials/my-nas,uid=33,gid=33,file_mode=0770,dir_mode=0770,vers=3.0,_netdev,nofail

[Install]
WantedBy=multi-user.target
EOF

Key tip: if you’re hitting the SMB3 encryption errors described above, pinning vers=3.0 explicitly (rather than letting the client negotiate the latest 3.1.1) sidesteps the more complex encryption negotiation that seems to trip up older Synology firmware.

5. Enable and start it

sudo systemctl daemon-reload
sudo systemctl enable --now media-ZIMASSD-nc\x2dsynology\x2dmount.mount
sudo systemctl status media-ZIMASSD-nc\x2dsynology\x2dmount.mount

You should see active (mounted). Check contents:

sudo ls -la /media/ZIMASSD/nc-synology-mount

Files should show up owned by uid/gid 33 (or whatever you set) — that’s what lets the Nextcloud container both read and write.

Tip: if you also want your own regular user to browse the mount for troubleshooting, add yourself to the www-data group (sudo usermod -aG www-data your_username) rather than loosening the file mode to something world-readable.

6. Expose the mount to the Nextcloud AIO container

This is the part that trips people up. A plain --volume flag on the AIO mastercontainer does not propagate to the actual nextcloud-aio-nextcloud container it spawns — the mastercontainer manages its own child containers and their volumes internally. Instead, AIO has a dedicated environment variable for exactly this purpose: NEXTCLOUD_MOUNT. It exposes a host directory inside the Nextcloud container at the same path.

Recreate the mastercontainer with this added (adjust the rest of your existing docker run flags accordingly):

sudo docker stop nextcloud-aio-mastercontainer
sudo docker rm nextcloud-aio-mastercontainer

sudo docker run -d \
  --init \
  --sig-proxy=false \
  --name nextcloud-aio-mastercontainer \
  --restart always \
  --publish 8080:8080 \
  -e APACHE_PORT=11000 \
  -e APACHE_IP_BINDING=0.0.0.0 \
  -e NEXTCLOUD_DATADIR="/media/ZIMASSD/nextcloud" \
  -e NEXTCLOUD_MOUNT="/media/ZIMASSD/nc-synology-mount" \
  --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  nextcloud/all-in-one:latest

Then restart all AIO containers from the AIO web interface (Stop containers → Start containers) so they pick up the change.

Verify the path is now visible inside the actual Nextcloud container (not just the mastercontainer):

sudo docker exec nextcloud-aio-nextcloud ls -la /media/ZIMASSD/nc-synology-mount

7. Add it in Nextcloud as Local storage

In Nextcloud: Administration settings → External storage → Add storage. Choose Local as the storage backend (not SMB/CIFS — the kernel already handled that layer), and enter the exact same path:

/media/ZIMASSD/nc-synology-mount

From Nextcloud’s point of view this now behaves like any other local folder — full read/write, previews, Office document editing all work through it, without Nextcloud ever having to negotiate SMB itself.

Tips & gotchas

  • Old external storage, new mount = re-index. If you’re migrating from an existing SMB external storage entry to this new local one, remove the old SMB entry after confirming the new one works, then re-run indexing for anything that depends on it (e.g. occ files:scan, or occ memories:index if you use the Memories photo app). The old entry’s cached metadata doesn’t carry over.

  • occ memories:index scans your whole library, not just the folder you point it at. If you’re using the Memories app, its indexing command walks your entire Nextcloud filesystem looking for media files — it’s not scoped to whatever you’ve set as your “timeline path.” That’s expected; it just means the first index after a big NAS migration can take a while.

  • Long-running index jobs and SSH sessions don’t mix well. If you’re indexing a large library (say, a terabyte of photos and videos) over SSH, detach the process with tmux, screen, or nohup so it survives a dropped connection or an accidentally closed terminal window.

  • Immutable host OS? Don’t forget: anything installed via a host package manager (apt, opkg, etc.) usually doesn’t survive an OS image update on appliance-style distros. Everything above — the mount unit, the credentials file, the NEXTCLOUD_MOUNT env var — lives in places that do survive (systemd units in /etc/systemd/system, data on your writable data partition), which is exactly why this approach is worth the extra setup step over trying to hack something together inside the Docker container itself.

  • Double connections, one at a time. If you keep other tools (e.g. Synology’s own Office suite) pointed at the same files, be aware they won’t coordinate file locking with Nextcloud Office/Collabora. Pick one editing path per file at a time to avoid conflicting saves.

  • Test with a throwaway file first. Before trusting this for anything critical, create a test file through Nextcloud and confirm it actually appears on the NAS side (and vice versa) before you migrate real data or delete any existing external storage entries.

1 Like