Correct and it is problematic to use SMB with an application that’s not the set up for the explicit use case. Say if you choose your data directory for immich and also set up with SMB. immich is going to make assumptions about what is in the directory when Photos could be deleted, renamed or moved. SMB is going to need to apply permissions from the user to that existing dataset. Those permissions could conflict rendering immich data unreadable or SMB unreadable.
A rule of thumb storage is to never exceed 80% of total capacity. 800 GB for a 1 terabyte of space. Does that change your projected needs?
I would say start out with your 16 GB of RAM and you can always add more RAM if needed. It’s one of the easiest things to upgrade.
Your motherboard doesn’t support PCIe bifurcation. It enables a larger slot, such as PCIe x16, to be split into multiple smaller lanes, such as PCIe x8 or x4. With support you can get a cheap pcie4.0 x16 to m.2 m-Key nvme x 4 ssd Expansion Card the more expensive route
Multi-NVMe (m.2, u.2) adapters that do not require bifurcation Down the road you’ll appreciate having NVME over SATA. So think about if you ever have to upgrade your motherboard. It’s the number one suspect for hardware failure years down the road.
Right now your motherboard supports the following PCI Express
PCI Express 3.0 x16 AMD Ryzen Processors
1 x PCIe 3.0/2.0 x16 (x16 mode)
AMD 7th Generation A-series/Athlon Processors
1 x PCIe 3.0/2.0 x16 (x8 mode)
PCI Express 2.0 x16 1 x PCI Express 2.0 x16 slot (max.@x4 mode) *3
*3 PCIeX16_2 slot shares bandwidth with PCIeX1_1 and PCIeX1_2.
PCI Express x1 2 x PCI Express 2.0 x1 slots
PCI Slots 2 x PCI Slots
For now SATA drives until your upgrade cycle for the server. I’ll doubt you get 10 years out of the motherboard.
Highly recommend Tailscale rather than exposing ports. If you must have exposed to the Internet Tailscale Funnel would be a better way to expose the server to the net. However as always use at your own risk.
I believe you’re describing the following Nginx Proxy Manager won’t deploy When setting it up in the UI add the ENV variable, S6_STAGE2_HOOK=sed -i $d /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh
I’m afraid I can’t really help you here application backup/restore isn’t really supported in ZFS or TrueNAS that is even remotely user-friendly. Please read the following as it expresses my thoughts on the issue. Does ixVolumes feels like it holds your data hostage? and TrueNas Scale needs a first party application backup and restore system
If anyone says just use host path that is not a true solution. database corruption can happen with the running application with the database being backed up live (transactions with the database might be interrupted). In this case simple ZFS snapshot won’t guarantee data integrity. These kind of things usually reveal themselves during restoring data. Obviously that’s the worst time. Shutting down the container before backup should mitigate these issues however host path has other issues.
I’ve had issues upgrading applications that have utilized host path leaving them in a broken state. One upgrade might go well, later it might break next upgrade. Since then truenas electric eel leveraging docker/docker compose. I can’t say whether or not that’ll have any improvement with the issue above. Bottom line upgrading applications is unreliable and we don’t have a real backup solution for applications. I would recommend to wait for a proper backup solution for applications rather than relying on some community guide.
I gotta say even ZFS snapshots are stupidly confusing. If you restore early in the timeline of ZFS snapshots it seems you lose the ability to restore to a later point because data is lost during restore. Makes experimenting restoring snapshots seemingly one a time deal.
If I could wave a magic wand it would be being able to restore a snapshot anywhere on the timeline and temporarily evaluate restored data. if the temporary restore looks good then commit that snapshot for permanent restoration pruning other snapshots that rely on the restored snapshot.
There is the option to clone the dataset instead of restore and you’ll have to reset up your applications to point to those paths but to me this is too much complexity. Backups should always be simple, transparent and automated. Truenas needs to take the human and system complexity out of backup and restore as much as technically possible.