1.5 KiB
Storage
Last updated: 2026-08-11
Overview
Shared storage is provided by a QNAP NAS over NFS. All Docker Swarm nodes mount the same NFS export, giving stacks a consistent data path regardless of which node a container lands on.
NAS
| Field | Value |
|---|---|
| Hardware | QNAP NAS |
| IP | 192.168.50.212 |
| NFS export | /DockerSwarmData |
Mount Points (Swarm nodes)
| Mount point | Purpose |
|---|---|
/mnt/DockerSwarmData/ |
Root of all shared Swarm data |
/mnt/DockerSwarmData/Projects/ |
Dev project source trees |
Docker Swarm stack data (volumes, configs, persistent state) lives under
/mnt/DockerSwarmData/.
Sharp Edges
NFS bind mounts can hide container-built assets
When a service generates files inside the container at startup (e.g. an app that seeds a config dir), an NFS bind mount will shadow the container's image-layer content with whatever is on the NAS — which may be empty on first deploy.
Mitigation: Prefer Docker named volumes when the image owns initial content. Use bind mounts only for data that already exists on the NAS or is explicitly managed outside the container.
SQLite on NFS is a footgun
NFS does not reliably implement POSIX file locking. SQLite depends on file locks for write serialisation. Running SQLite (or any lock-dependent embedded DB) on an NFS mount under concurrent writes will cause corruption.
Mitigation: Run SQLite databases on local node storage, or replace with a
network-capable database (Postgres, MySQL) on memory-archives.