docs: fix nas_media docker volume opts after 2026-09-16 outage

Host reboot broke the nas_media Docker NFS volume for 6+ hours (plex,
qbittorrent x3, navidrome, sonarr, jellyfin all down): nfs-utils 2.6.4 no
longer accepts the ":/path" + addr= device split, and separately Docker's
local volume driver can't do nfsvers=4 (calls mount(2) directly, skipping
the mount.nfs helper's version negotiation). Volume recreated with an
explicit host:/path device and vers=3. Updating docs/comments to match
the corrected live config so the next person doesn't recreate the same
broken volume from the stale example.

NAS-CONNECTION-STRATEGIES.md

@@ -107,7 +107,8 @@ Summary of how each service connects to the unRAID NAS (192.168.1.192 / 192.168.
 
 ## Known Issues & Gotchas
 
-- **Docker NFS named volumes**: The `nas_media` volume uses `soft,nolock,timeo=14,nfsvers=4`. This is fragile — short timeout means EIO on spin-up. Plex/qBittorrent survive because they open/close handles per request. If either starts having I/O errors, migrate to the systemd permanent mount pattern.
+- **Docker NFS named volumes**: The `nas_media` volume uses `soft,nolock,timeo=14,vers=3`. This is fragile — short timeout means EIO on spin-up. Plex/qBittorrent survive because they open/close handles per request. If either starts having I/O errors, migrate to the systemd permanent mount pattern.
+- **Docker's local NFS volume driver requires `host:/path` in `device`, and can't do NFSv4**: it calls `mount(2)` directly rather than shelling out to the `mount.nfs`/`mount.nfs4` userspace helper. Two consequences, both hit in the 2026-09-16 outage below: (1) nfs-utils 2.6.4 (Ubuntu 24.04) rejects the old `device=":/path"` + separate `o=addr=<ip>` split form - the host must be in the device string itself now (`device=<ip>:/path`); (2) `vers=4`/`nfsvers=4` fails with "protocol not supported" via the raw syscall even though a manual `mount -t nfs -o nfsvers=4 ...` succeeds (that goes through `mount.nfs`, which does version negotiation the raw syscall skips). Stick to `vers=3` for any Docker-managed NFS volume on this host.
 - **Docker bind mounts + automount = stale handles**: Docker snapshots the mount reference at container start. If autofs cycles (unmount + remount) between container restarts, the container's bind mount goes stale while the host sees the path fine. Fix: use permanent `.mount` (no `.automount`) for any share that Docker containers bind-mount.
 - **SQLite on NFS**: Never store SQLite databases (calibre `metadata.db`/`notes.db`, any app DB) on NFS. Even with `hard` mounts and NLM locking, transient NFS errors cause `SQLITE_IOERR`. Keep SQLite on local SSD; sync non-SQLite files to NAS if sharing is needed.
 - **CIFS vs NFS for file permissions**: CIFS enforces server-side ACLs based on the SMB user. Files created via NFS by uid=99 with mode 600 are inaccessible via CIFS. Use NFS when container needs uid-mapped access to NFS-created files.

torrents/docker-compose.yaml

@@ -53,13 +53,17 @@ services:
       - nas_media:/data
 
 volumes:
+  # External volume; actual definition lives in `docker volume create` (see
+  # NAS-CONNECTION-STRATEGIES.md). Current opts (fixed 2026-09-16 after a
+  # host reboot broke this): type=nfs, vers=3 (not 4 - Docker's local volume
+  # driver calls mount(2) directly rather than through the mount.nfs
+  # userspace helper, which fails with "protocol not supported" for
+  # nfsvers=4 on current nfs-utils/kernel), device=192.168.1.192:/mnt/user/media
+  # (host must be in the device string itself now, not split into a
+  # separate addr= option - nfs-utils 2.6.4 on Ubuntu 24.04 no longer
+  # accepts the old ":/path" + addr= form).
   nas_media:
     external: true
-#    driver: local
-#    driver_opts:
-#      type: nfs
-#      o: "addr=192.168.1.192,rw,nolock,soft"
-#      device: ":/mnt/user/media"
 
 networks:
   default: