Sarah Reid

You don’t actually need Duplicati on her end at all, Duplicati can back up to a plain SFTP or WebDAV target, or S3, so her side just needs to recieve files. The simplest setup I’ve seen for a non-technical friend is SFTPGo in Docker over Tailscale, it has a web UI for managing a user and a folder, and nothing is exposed to the internet.

Keep the encryption on your side, Duplicati encrypts before upload, so she only ever sees encrypted blobs, and store the passphrase somewhere seperate from the backup itself. Set a quota if you can, agree on how much disk she is giving you, and test a restore to a spare folder once, a backup you haven’t restored is just a hope. FYI scheduled backups plus a monthly restore test is what actually saves you when a disk dies.

This is the exact trap with agents, they will use whatever privilege is lying around, they don’t stop and think ‘should I?’ like a person might. The docker group really is root, just with extra steps, so anyone in it can mount the host root fs and write to /etc.

What worked for me: run the agent as a seperate unprivileged user with no docker group at all, rootless Podman if you can, and give it a dedicated project dir only. Mounts read-only where possible, no host socket, no --privileged, and keep it off your real home dir and secrets. FYI I also log everything it runs and review the diff before anything gets applied, because the audit trail is the only way you notice it doing something sneaky after the fact. YMMV on tooling, but the principle stays the same, least privilege plus a sandbox you actually trust in your enviroment.

Mount it in the VM, not as Proxmox host storage — that keeps a dead NAS from hanging Proxmox itself, and you can reboot or move the one VM without touching the host. FYI, use nofail with automount rather than a plain entry that blocks boot, so the VM still comes up if TrueNAS is offline when it starts.

Give each Docker service its own dataset/share instead of one big share for everything, so one service filling or locking a share doesn’t take the rest down. And keep anything that can’t tolerate a stall — database files especially — on local disk in the VM, with only bulk media/files on the NFS mount. Test it once by taking TrueNAS offline on purpose and watching what the containers do; that’s when you’ll find out if a hang occured rather than a clean error. Seperate shares also make permissions easier to fix per service, since you’re already dealing with the ownership issues tofu mentioned.