Does yours have 8 sata ports or dual external sf8088 ports per chance and moreram?

Because if you use relative bind mounts you can move a whole docker compose set of contaibera to a new host with docker compose stop then rsync it over then docker compose up -d.

Portability and backup are dead simple.

you need to create a docker-compose.yml file. I tend to put everything in one dir per container so I just have to move the dir around somewhere else if I want to move that container to a different machine. Here’s an example I use for picard with examples of nfs mounts and local bind mounts with relative paths to the directory the docker-compose.yml is in. you basically just put this in a directory, create the local bind mount dirs in that same directory and adjust YOURPASS and the mounts/nfs shares and it will keep working everywhere you move the directory as long as it has docker and an available package in the architecture of the system.

`version: ‘3’ services: picard: image: mikenye/picard:latest container_name: picard environment: KEEP_APP_RUNNING: 1 VNC_PASSWORD: YOURPASS GROUP_ID: 100 USER_ID: 1000 TZ: “UTC” ports: - “5810:5800” volumes: - ./picard:/config:rw - dlbooks:/downloads:rw - cleanedaudiobooks:/cleaned:rw restart: always volumes: dlbooks: driver_opts: type: “nfs” o: “addr=NFSSERVERIP,nolock,soft” device: “:NFSPATH”

cleanedaudiobooks: driver_opts: type: “nfs” o: “addr=NFSSERVERIP,nolock,soft” device: “:OTHER NFSPATH” `

dockge is amazing for people that see the value in a gui but want it to stay the hell out of the way. https://github.com/louislam/dockge lets you use compose without trapping your stuff in stacks like portainer does. You decide you don’t like dockge, you just go back to cli and do your docker compose up -d --force-recreate .

That’s the dude who was butt hurt about something this dude did: https://github.com/iamadamdev/bypass-paywalls-chrome

and so forked it and arguably does a better job, lol.

virtualize the machine with proxmox, use proxmox backup server, load vm on new system if you get catastrophic failure on the machine running the vm currently.

will it let you do rootless nfs mounts into the container? That’s the showstopper for me, as that is by far the best way to just make this all work within the context of my file storage.

I started on planka but ended on vikunja, it was just a lot nicer and more flexible for my needs.

how does this compare to: https://github.com/babybuddy/babybuddy (I used babybuddy for my two kids, it was great)

It’s really easy with headscale so I assume it must be really easy with tailscale too. How I did it was I created tiny tailscale vm to advertise the route to the ips I wanted access to on my internal lan. Then I shared the nfs share with the ip of that subnet router. now everything on my headscale network looks like it’s coming from the subnet router and it works no problem (Just remember you have it setup this way in case you ever expand your userbase, as this is inherently insecure if there is anything connected to your tailscale that you don’t want to have full access to your nfs shares)

I really like truenas for nas but I agree with you on running vms/docker somewhere else. I ended up keeping truenas for the mass storage (the only thing I run on it is one virtual machine to hold proxmox backupserver on an ivol). I think the much better home platform for vms is proxmox. You get ar eally nice gui that makes everything pretty easy, it’s debian under the hood and with proxmox backup server you can very easily backup your virtual machines. It’s also very easy to mount nfs or cifs shares into docker containers so you can keep the bulk data of your docker environment directly on the nas, which makes managing backups dead simple.