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.
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.