What filesystem are you using on the external drive? If it is NTFS or FAT, they won’t store permissions on the filesystem, which would explain why the owner/group changes are not persistent. To fix that, you can set the uid/gid on mount in your fstab.
/dev/mapper/YOUR_DRIVE /path/to/mnt <fstype> rw,uid=<jellyfin_uid>,gid=<jellyfin_gid>,dmask=0002,fmask=0113
Are you using the default bridge? I have a similar setup (with Traefik instead of NPM), and for each compose file am using separate networks for the internet, proxy, and backend services.
services:
some_service:
...
networks:
- frontend_network
- proxy_network
- backend_network
backend_service:
...
networks:
- backend_network
networks:
frontend_network:
driver: "bridge"
proxy_network:
driver: "bridge"
internal: true
backend_network:
driver: "bridge"
internal: true
The more bits per cell you store, the more dense and therefore cheaper your flash chips can be for a give capacity. The downside is that it is slower and less reliable since you have to be able to write and read exponentially more voltage states per cell, e.g. 2 states for SLC, 4 states for MLC, 8 states for TLC, etc.
I’ve been using PhotoPrism for the past couple of days and have really liked it.
I was considering Immich, but the rapid development cycle turned me off of it for now. I don’t want to have to deal with keeping up with patch notes and potential breaking changes. Immich also seems more focused on photo backups from your phone, which isn’t quite what I wanted. PhotoPrism just let me upload all my existing photos on the web ui.
I’d say give both a try. Both provide a docker-compose file, so you should be able to bring them up fairly quick.
I think the snapshot exists but is not mounted as a btrfs subvolume.
Is it not listed when you try running btrfs subvolume list .? You might need to change the . to a path that is on the array.
from the research I did, the @docker folder at the volume root holds all the volumes, images, subvolumes, etc. and I did copy that over.
Copying over the files wouldn’t be enough. You would actually need to create the subvolumes, e.g. btrfs subvolume create subvolume_name.
Do you happen to know if I find the snapshot folder and download it, will there be anything recoverable? Or would it just be like, hashes and unintelligble stuff?
Unfortunately, I am not familiar enough with how Synology does things, but a btrfs snapshot will just appear as normal directory with the files/directories in it. If Synology isn’t using btrfs for the snapshoting, I’m not sure what you’ll find.
I’ll preface this by saying I am not familiar with Synology, but I am using Docker and BTRFS (which I am assuming is being used on your Synology NAS).
Do you have SSH access or the ability to get a shell on the NAS? If you do, you can try running btrfs subvolume list . to see what subvolumes/snapshots are on your system. That will hopefully let you figure out where your data is. Once you narrow down where it is, you can try downloading it using an sftp client.
As an aside, the reason Docker threw a fit whenever you tried to update an image is that Docker was probably automatically using the BTRFS driver, which creates a new subvolume/snapshot for every image/layer. When you remove images, it would just remove all the subvolumes/snapshots. When you copied your files over, you probably didn’t remake the subvolumes. That would have caused issues when trying to remove images, or create new images/containers.
How are you passing the drives to the TrueNAS VM?
It’s your private key, but yes, you would need to keep it secret just like you would an SSH key.
The benefits of a VPN are that you don’t need to open ports up to the internet and rely on your individual services to be secure. Your VPN would authenticate users and ensure that the communication over the tunnel is encrypted (useful if you don’t want to set up SSL/https). They can also hide what services you are hosting or even hide the fact that you are even running a VPN.
Private keys are going to be far more secure than passwords since you really can’t brute force them in the same way you can passwords. Getting ahold of someone’s private key is probably going to be far more difficult than guessing their password. Even if an attacker were to get ahold of your private key, they would still need to contend with the security of your service, e.g. logging into it, which would be no worse than not having a VPN.
This really depends on your threat model. If you are only concerned about the drive getting stolen, or wanting to keep the data on it private if you need to RMA the drive, mounting it automatically on boot with a key stored on the rootfs can be perfectly fine. If you are a journalist in a hostile country and protecting your sources from state level actors is a matter of life and death, then yeah, this would be woefully insufficient.