50 lines
1.5 KiB
Markdown
50 lines
1.5 KiB
Markdown
# 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`.
|