bmartino1

Thata looks good...


Configure NFS on Unraid
On Unraid (GUI):
Settings → NFS
Enable NFS: Yes
Apply
Shares → YourShareName
Set Export: Yes
Security (recommended):
Private
Rule example:
<ubuntu_ip>(rw,sec=sys,async,no_subtree_check) Apply
💡 If testing, you can temporarily use Public to rule out permission issues...


First UBUNTU...

Install NFS client on Ubuntu Server
sudo apt update sudo apt install -y nfs-common Verify:
mount.nfs --version
Next selcet a path on ubuntu to mount the nfs... lets use /mnt simlar to what unraid does...

Create a mount point
Pick where you want the share mounted:
sudo mkdir -p /mnt/unraid sudo chown root:root /mnt/unraid sudo chmod 755 /mnt/unraid (You can adjust ownership later if a non-root user needs access.) this is ubuntu user and access to the folder stuff...

Test the NFS export (important)
List available exports from Unraid:
showmount -e <UNRAID_IP> You should see something like:
/mnt/user/media this would be the path to your unriad host that is being shared...
If this fails → firewall, NFS not enabled, or export misconfigured...

Manual mount (test before fstab)
sudo mount -t nfs <UNRAID_IP>:/mnt/user/YourShareName /mnt/unraid Verify:
df -h | grep unraid ls /mnt/unraid If this fails, stop here—don’t touch /etc/fstab yet. To make it permeant upon ubnut reboots to auto conect the share


Fix permissions (very common gotcha)
Unraid typically uses:
UID 99 (nobody user)
GID 100 (Users group)
Check on Ubuntu:
ls -ln /mnt/unraid If you see permission issues, either:
Option A — match UID/GID (recommended for servers)
sudo usermod -u 99 youruser sudo groupmod -g 100 yourgroup Option B — force UID/GID in mount options
(Useful for Docker hosts)
sudo umount /mnt/unraid sudo mount -t nfs -o rw,vers=3,hard,timeo=600,retrans=5 <UNRAID_IP>:/mnt/user/YourShareName /mnt/unraid Persistent mount via /etc/fstab

Edit ubuntu cofig:
sudo nano /etc/fstab Add one of these (recommended options shown):
Stable & compatible (best default)
<UNRAID_IP>:/mnt/user/YourShareName /mnt/unraid nfs rw,vers=3,hard,_netdev,noatime 0 0If you know you want NFSv4
<UNRAID_IP>:/mnt/user/YourShareName /mnt/unraid nfs4 rw,hard,_netdev,noatime 0 0Apply without reboot:
sudo mount -a Validate after reboot of ubuntu
reboot df -h mount | grep nfs
Other side errors and fixes:

Common fixes if something breaks
❌ mount.nfs: access denied
Share not exported
IP not whitelisted
Wrong export path (/mnt/user/... vs /mnt/diskX/...)
❌ Hangs at boot
Missing _netdev in fstab
Network not ready yet

For a beginner with your hardware and goals: run Unraid bare-metal first.
Skip Proxmox-for-now. You’re not missing out on anything critical, and you’ll learn much faster with fewer moving parts.


Model A — Unraid as the platform (recommended for you)
Unraid is the OS
Storage, Docker, light VMs all live together
You get:
Disk spin-down
Dead-simple Docker UX
Community Apps (huge win for beginners)
Minimal hardware abstraction to understand
Model B — Proxmox as the platform
Proxmox controls everything
Unraid becomes “just another VM”
You must understand:
PCIe passthrough
IOMMU groups
Storage layers (ZFS/LVM → VM disk → filesystem)
Backup strategies across hypervisor boundaries
This model is powerful, but it’s not beginner-friendly, and it does not actually reduce risk early on.
Your hardware is already perfect for Unraid
You’ve got an ideal Unraid box:
i5-12600K → plenty of cores for Docker + Plex/Jellyfin transcoding
64 GB RAM → massive headroom
Large HDD array → Unraid parity model shines here
Multiple NVMe drives → perfect cache/appdata layout
Unraid’s value proposition (mixed disks + spin-down) is weakened when virtualized.
Q/A
1. “Should I virtualize Unraid in Proxmox?”
No, at least not now.
Why this advice keeps coming up:
People coming from enterprise or ZFS worlds
People who already understand hypervisors
People optimizing for snapshot-heavy VM workloads
Why it’s not ideal for you:
SATA/NVMe passthrough adds fragility
Debugging disk issues gets harder, not easier
You lose Unraid’s simplicity benefit
If something breaks, you now have to ask:
That’s not a fun learning experience.
2. “Does Docker inside Unraid defeat isolation?”
This is a very common misconception.
Reality:
Docker already provides process, filesystem, and network isolation
99% of homelab services do not need VM-level isolation
Security risk is dominated by:
exposed ports
weak auth
bad reverse-proxy config
Unraid Docker isolation is more than sufficient for:
Immich
Paperless-ngx
Jellyfin
Arr stack
AdGuard / Unbound
VMs ≠ automatically safer. portainer and dockers can run in a LXC on proxmox or another VM like debian,ubuntu, OMV...
3. “Second Unraid instance for Docker?”
You’re correct:
❌ Requires another license
❌ Adds complexity
❌ Solves a problem you don’t actually have
Not recommended.
4. “Single Debian VM for Docker?”
This only makes sense if:
You already dislike Unraid’s Docker UI
You want to manage everything via Compose/Git
You’re comfortable debugging Linux networking
Otherwise, it’s strictly harder than native Unraid Docker.
You also lose:
Automatic appdata mapping
Community App templates
Simple backup tooling
5. “Multiple VMs/LXCs per service?”
This is enterprise thinking applied too early.
Trade-offs:
✔ Clean blast-radius boundaries
❌ Disk sprawl
❌ Backup complexity
❌ RAM overhead
❌ Management fatigue
For homelab services that mostly:
talk over HTTP
read/write files
sit idle 90% of the time
…it’s unnecessary.
How Unraid actually manages hardware (simplified)
This is important for peace of mind:
Disks
Each HDD is an independent filesystem
Parity is computed at the block level
No RAID rebuild storms
Cache (NVMe)
Btrfs RAID1 → redundancy for appdata/VMs
Docker
OverlayFS on cache
Direct host access (no nested virtualization)
VMs
KVM, optional IOMMU
Only needed for Windows / special cases
You don’t have to think about “who owns the hardware” like in Proxmox.
About NVMe boot support
No. Don’t wait.
USB boot is stable and proven
The boot device is barely touched after startup
Migrating later will be trivial
This shouldn’t block you from learning today.
A clean, beginner-proof recommendation
Phase 1 — Start here (weeks to months)
Bare-metal Unraid
HDD array + NVMe cache (RAID1)
Docker via Community Apps
Maybe one VM if you truly need it
Learn:
Shares
Cache behavior
Docker networking
Backups
Phase 2 — Optional evolution
If later you think:
Then:
Add a Debian VM
Or migrate to Proxmox with confidence
At that point, you’ll know why you’re doing it.
Final take
You’re not making things too simple—you’re accidentally making them too complex too early.
Unraid’s biggest strength is that it lets you:
That’s exactly what you want as a first homelab.
If you want, next we can:
design a disk/cache/share layout
map which services belong where
or plan a future Proxmox migration path without locking you in
You’re on the right track 👍

the docker also needs to have dvb driver support, something I know the official plex and linuxserve does have. binhex docker tag version may not have the needed packages installed...

To q/a, correct the extra parm is essential the docker run statements at the end that do other options.

example my makemkv for the blueray disk


please post a diag file I would need to know more on the lsusb and lspci to help make a device extra parm for your Tuner. to go over other advance pass techniques. (would be useless if its docker software issues not hardware pass issues...) So my assumption/ bet at the moment is docker software...

My guess is that its the docker image does not have dvb software installed. *Similar to you installing the plugin on unraid to see the tuner, plex docker container needs simalr software...

I would recomend changing the repo to linux server keeping binhexs plex temptle and paths as they are/can be universal between tempatles...


lscr.io/linuxserver/plex

and adding some other extra docker variables:


as again this works fine in linux server and plex offical...

that said with binhex you could atempt to install the missing software ... not sure the applciaiton names though nor other adational libs that may be required...
https://hub.docker.com/r/linuxserver/mods

(as you can see by my compose i'm extra installing the sqlite pacakges to be able to run teh sq db stuff in the docker...)

FIRST!
make sure the adapter tuner is making it into plex:
console into your plex and ls the dvb dev folder...





but again i don';t think binhex plex has the needed dvb software in the container...

unraid uses openzfs for its implementations... I wil try to anser your q/A

Is the ZFS ARC shared across all pools?
Yes.
The ARC (Adaptive Replacement Cache) is a system-wide RAM cache managed by the ZFS module in the kernel. It is not tied to individual pools — it caches data from all ZFS pools/datasets on the system in one shared memory space. see https://www.reddit.com/r/unRAID/comments/16sy787/how_much_of_my_zfs_arc_belongs_to_each_drive/
So if you have multiple ZFS pools, they all draw from the same global ARC. You don’t get separate per-pool RAM cache partitions.
Unraid has a modprobe and a default # set.



there are terminal command to check it and this can be edited...

Can ARC be limited or tuned per pool?
No — ARC tuning is global.
Settings like zfs_arc_max, zfs_arc_min, or other ARC parameters are module parameters for the ZFS subsystem, not per pool. You configure them once (typically via module parameters or sysctl) and they affect ARC behavior for all pools. see https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html
There isn’t a ZFS native feature to assign different ARC limits per pool or per dataset in Unraid.

What about L2ARC?
L2ARC is per pool.
L2ARC (second-level ARC) is effectively an extension of the main ARC residing on fast storage (usually SSD or NVMe).
Each pool can have its own L2ARC devices, and ZFS does not share a single L2ARC device across multiple pools by default. If you want separate L2ARC for each pool, you attach a cache vdev to that pool.
Because L2ARC must be explicitly added as a cache vdev to a pool, it’s inherently pool-specific.
https://www.youtube.com/shorts/9kJPJx1OZrQ

Other ZFS tunables like l2arc_headroom, zil_nocacheflush, etc.
These module parameters or kernel tunables are global, not per pool.
Parameters like l2arc_headroom, l2arc_noprefetch, etc. are ZFS module parameters that affect how the entire ZFS subsystem behaves, not just one pool.
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html
This means you set them once for the system, and they apply to all pools that have L2ARC devices.
As it stands, there isn’t a built-in way in ZFS (nor in Unraid’s ZFS integration) to configure these parameters on a per-pool basis.

the easiest solution if you are just looking to disk clone the system disk of the studio pc to a unraid share... I would have you look into clonezilla this would boot on the Other system but conect and save its disk cone on a unraid share...

https://clonezilla.org/
Example of on screen ono the stuid sytem to clone:
https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/01_Save_disk_image

on the studio mahcine once a month after seting up clone zilla to automate, connect to a unarid samba share and make a disk clone. using unriad as a nas.
I would then cloe the studio pc to a unraid disk image...

Or you could run a clone zilla docker.
https://hub.docker.com/r/theniwo/clonezilla
then installing soemthign like
https://www.bacula.org/
on the studio pc and have it clone / backup files to a unraid share.

many ways to accomplish this. just would require some scripting

it comes down to how you want to interact iwth it and what you wnat it to do, but this is totally achievable.

Usually this is called a ingesting system. when a disk gets conected and is auto clones, copied. Symantec Nortan ghost is a good one.
as there are many software varients of this. but if you want free you need to script it your self.

This is a very common ZFS situation, and the wording of the message is scarier than what’s usually going on....

From your output:
state: ONLINE status: One or more devices has experienced an error resulting in data corruption. ... md2p1 ONLINE 0 0 28 errors: 35 data errors Key facts:
The pool is ONLINE
There are no read or write errors
There are checksum (CKSUM) errors
ZFS detected 35 blocks whose checksums did not match
ZFS cannot silently fix them because this is a single-disk pool
This is detection, not failure — and ZFS is doing exactly what it is supposed to do.

Why the files “work fine”
ZFS errors are block-level, not file-level.
That means:
A corrupted block might be:
unused padding
metadata that isn’t currently read
part of a compressed block that still decompresses
part of a file that hasn’t been touched yet
Many apps do not notice minor corruption immediately
ZFS never guesses — if a checksum mismatches, it records it permanently
So “the file opens” ≠ “the data is correct”.
ZFS is more strict than most filesystems — that’s a feature.

What the SCRUB button does (important)
A scrub:
Reads every block in the pool
Verifies every checksum
If redundancy exists (mirror / RAID-Z):
Automatically repairs bad blocks
If redundancy does NOT exist (single disk):
Confirms and logs corruption
Cannot repair
A scrub does not:
delete data
rewrite files
fix corruption without redundancy
Think of scrub as a full audit, not a repair tool.
What you should do — step by step
*Run a scrub (yes, press the button)

Or from CLI:
zpool scrub disk2 Check progress:
zpool status disk2 This confirms:
whether the error count increases
whether corruption is stable or ongoing
As you may have a bad disk inteh zfs setup that needs replaced...

List exactly which files ZFS thinks are bad
You already ran -v, but for completeness:
zpool status -v disk2 You’ll see paths like:
/mnt/disk2/some/path/file.ext If the same files reappear after scrub → confirmed corruption.

If the files are non-critical
If you don’t care about those files:
rm /mnt/disk2/path/to/file zpool clear disk2 Then scrub again.
This often resolves the warning permanently.

If the files matter
ZFS cannot repair without redundancy.
Your options are:
Restore the affected files from backup
Re-copy them from a known good source
If unsure → delete and re-ingest
After replacement:
zpool clear disk2 zpool scrub disk2 What zpool clear actually does
zpool clear disk2 This:
clears the error counters
does not erase history
does not hide future errors
is safe to run after addressing the cause
If corruption still exists, it will reappear.

Important diagnostic checks (do these)
*SMART check (very important)
smartctl -a /dev/sdX Look for:
Reallocated sectors
Pending sectors
CRC errors
Read errors
Checksum errors often come from:
marginal sectors
bad SATA cables
power instability
RAM errors (ECC strongly recommended)
see openzfs docs:
https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A/

more info on the scrub:
https://openzfs.github.io/openzfs-docs/man/v2.4/8/zpool-scrub.8.html

Bottom line
SCRUB = full integrity scan
Single-disk ZFS cannot repair, only detect
“Files work” does not mean “no corruption”
ZFS is behaving correctly
This is not panic-level unless errors grow
Potential bad disk needs replacement

web UI updates are for docker tages repos only.

if the xml is removed from the CA it was removed for a reason. Thus maintain the tempalte/docker is now on you. I would recommend reusing the temple and change the docker tag to a trusted version or use the new/current model for authentik. (no reason to remove if the docker is still working and getting docker tag updates)

looks like zuerrex is mainting them now for unraid.


This means you would need to use there docker tempatle and tag to get better support on the forum...

xml is never updated you must delete it and redownlad form the CA. as explained above...
example of XML I maintain for the CA
https://github.com/bmartino1/unraid-docker-templates

it can take 2-4 hours after I edit a template before the CA is updated to use one of my xml templates.

I personaly have become more partial to using docker compose. unraid plugin to use compose on unraid...

This method is called sidecar and is and can be used in conjunction with other dockers and docker networks...

You should run the wg docker in custom br0/eth0/bond0 (depending on your network connections..)

https://www.youtube.com/watch?v=bKFMS5C4CG0

Brandon Martino - Personal Site
Guide-DockerNetworks
Brandon Martino - Personal Siteonce you get your wiregaurd instance up you would usualy use container network this WireGuard docker name or docker network cli commands to connect things to this docker...

also you need to pass cap system to the docker due to the tunnel and access to network tunnels...

when messing with mutiple docekr networks on unraid I pref to use compose... as teh unraid docker tempates build a docker run line and some edits, option and data is not there to use the system...


so to clerify your docker is missing some key data...

this is not a missing kernel module, it’s a Docker capability / device permission failure on Unraid.
*That means the container is not allowed to create a network interface.

WireGuard inside a container needs three things that Docker does not grant by default:
Capability to create network interfaces
Capability to configure them
Access to /dev/net/tun
Without those, wg-quick up wg0 will always fail exactly like this.

Potental Fixes:
add this line to your extra parm:
--cap-add=NET_ADMIN --cap-add=SYS_MODULE --cap-add=NET_RAW --device=/dev/net/tun


and use docker network mode host or custom br0...

again I prefer compose i would run this...


#version: "3.8" services: wireguard: image: ghcr.io/wg-easy/wg-easy:latest container_name: wireguard network_mode: host cap_add: - NET_ADMIN - SYS_MODULE - NET_RAW devices: - /dev/net/tun:/dev/net/tun volumes: - /mnt/user/appdata/wireguard:/etc/wireguard environment: # UI - WG_HOST=your.public.ip.or.dns - PASSWORD=change-me # Optional tuning - WG_PORT=51820 - WG_MTU=1420 - WG_PERSISTENT_KEEPALIVE=25 restart: unless-stopped Why this works (and your error goes away)
network_mode: host
WireGuard must create a real kernel interface (wg0)
Host mode avoids Docker NAT entirely
NET_ADMIN
Required for ip link add wg0
/dev/net/tun
Required for tunnel device
NET_RAW
Needed for packet handling (especially on Unraid)
SYS_MODULE
Lets WireGuard load kernel helpers if needed
(Unraid already has WG, but this avoids edge cases)
mkdir -p /mnt/user/appdata/wireguard
*Docker required the folder pre-made... using unrad defaults!

This will store:
wg0.conf
keys
peer configs

Many ways to accomplish the same thing. as this is why unraid added WireGuard stuff to the host level ...

lattest update seems to have fixed most if not all of my errors

2025.12.19.2020 
 up-to-date

While not all error are fixed, progress is being made where connect is usable once more.

lattest update seems to have fixed most if not all of my errors


2025.12.19.2020 
 up-to-date

https://www.reddit.com/r/unRAID/comments/14zq1mz/video_guide_array_disk_conversion_to_zfs_or_other/

you in a older intel generation but that shouldn't matter. I would upgrade teh ram form 4 GB to 8 GB. 16 recommend. Unriad loads and exist in ram and when you add other docker and complex systems on top like using zfs that requires more ram and resources.
unraid is more software raid I wouldn't recommend runnign disk in raid 1/0or JBOD via Bios MotherBoard. Let unraid handle the disk.

Manage storage | Unraid Docs


https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/overview-and-system-prep/

The minimum Unraid requirements are a 64-bit CPU, at least 8 GB of RAM (4 GB for very basic use), a USB 2.0 or 3.0 flash drive (4-32 GB) with a unique GUID, and a Gigabit Ethernet connection
https://forums.unraid.net/topic/119052-psa-on-sandisk-usbs/

This machine is a good cheap starter addation with unraid 7.0 Depending on disk and space a (no array setup) a single cache disk 1 TB HDD is more then enough to get started.

Is it possible to upgrade a dump made by postgres 16 to version 18?

yes I have done this recenlty my self to trest teh image genis unraid CA form postgress v16 to v18.
When you restore form a backup your porvious immich postgress v16 data sucah as user name and passowrd are over writeen so you will need to maintin v16 credentals if you restore.

https://medium.com/@damngoodtech/how-to-easily-restore-a-postgresql-database-in-a-docker-container-23ccfaa3d60b

I would use a immich last backup sql file made. or use pgadmin a third party docker to connect ot hte database and dump its contents.

the goal is to unziip/extract the files inteh zip/tar etc to get to you sql file

One can then follow guide:
https://davejansen.com/how-to-dump-and-restore-a-postgresql-database-from-a-docker-container/

I then to use a docker varable and samba to use 7zip to extract the archived backup to get my sql file then add a tempatle edit and docker varbale to pass the file into the continer...

then i would use unriad docker webui to console conect to get a termainl windows of the docker container and run the comands pointing at the file I passwed in the folder...

There is no one size fits all and many way to acomplish this.

as the goal is to excute the sql file in the postgress database tag version you want.

this is a intel i915 driver issue with unraid kernel drivers.

Please install the intell i915 driver. The intel gpu top plugin...


And if needed (depending on the board the beta driver...)


00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-S GT1 [UHD Graphics 770] [8086:4690] (rev 0c)
Subsystem: Super Micro Computer Inc Device [15d9:1c48]
Kernel driver in use: i915
Kernel modules: i915, xe

unraid emhttp web ui is on the same ports for npm. either change the ports for unraids webui port 80 and 443 or edite the docker bridge ports to docekr nat other ports for npm..

I prefer to use custom br0 and give npm its own statsic IP lan for easier management and no port issues...

to start over you may need to delete the npm folder and files in the appdata folder.

uer script plugin at frist arry boot

sysctl -w fs.inotify.max_user_instances=1024



What I Run:

#!/bin/bash # Delay before starting sleep 10 # Apply sysctl settings apply_sysctl_settings() { echo "Applying sysctl settings..." sysctl -w net.ipv6.conf.all.forwarding=1 sysctl -w net.ipv6.conf.br0.accept_ra=2 #sysctl -w net.ipv6.conf.br0.accept_ra_rt_info_max_plen=64 echo "Verifying sysctl settings..." sysctl net.ipv6.conf.all.forwarding sysctl net.ipv6.conf.br0.accept_ra #sysctl net.ipv6.conf.br0.accept_ra_rt_info_max_plen } #run loop apply_sysctl_settings for ipv6 forwarding to ha docker..

unasigned disk. zfs via terminal. use of zfs send recieve... This is iondeed posible. I find ti easier to use teh zfs send recvie when zfs shares the same pool name...

You can do this cleanly without taking the Unraid host down. The key is to treat the “cold” shelf as a ZFS pool that you export before you power it off and import only when you need it. With Unraid 6.12+ ZFS integration, you don’t need to stop the whole “array” to do that—just don’t let the cold pool auto-mount at array start.

Define the layout (If I'm reading this corectly...)
Host: Dell XC630 (HBA → external SAS) running Unraid (no parity array).
Hot storage: Two NetApp NAJ-1502 12-bay SAS3 JBODs → your two HDD ZFS pools (24/7).
Fast tier: NVMe ZFS pool (24/7).
Cold storage: Dell MD3060e (SAS2 60-bay) → one ZFS pool used as a monthly on-site replica (powered OFF except during sync windows).

Unraid behavior you’ll rely on?
ZFS pools can be managed independently of the Unraid “array.” You can:
Disable automount on array start for the cold pool.
zpool export the cold pool, power the shelf off, and keep the server up.
Later power the shelf on and zpool import the pool, so no host reboot needed.
Docker/VMs: ensure nothing points to the cold pool path when it’s offline (disable any shares that include that pool, or use separate share names).
FYI: Unraid doesn't support sas hotplug...
Hardware handling (SAS JBOD etiquette)
Before power-off: make sure the pool on that shelf is exported (not merely unmounted). Export tells ZFS “these vdevs will disappear,” avoiding error spam and pool faults.
Power sequencing: generally power JBOD(s) on first, wait 30–60s for link up, then import (host can already be running). For power-off, export → power down the shelf.
you will need a onetime migration to send the data form your current setup to the new ready to go system...

One-time migration from MD3060e → NetApp shelves
Assume:
Old hot pools on MD3060e: tankA_old, tankB_old.
New hot pools on NetApp: tankA, tankB.
You’ll move datasets via snapshot + zfs send | zfs recv.

Example scripts (using zfs send receive)
https://openzfs.github.io/openzfs-docs/man/master/8/zfs-send.8.html
https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.html

Create the new pools (example raidz2 vdevs; adjust to your layout):
# Example only — pick your desired vdev geometry zpool create -o ashift=12 \ -O compression=zstd-3 -O atime=off -O xattr=sa -O acltype=posixacl \ -O normalization=formD -O relatime=on -O dnodesize=auto \ tankA raidz2 /dev/disk/by-id/wwn-disk1 ... /dev/disk/by-id/wwn-disk8 zpool create -o ashift=12 \ -O compression=zstd-3 -O atime=off -O xattr=sa -O acltype=posixacl \ -O normalization=formD -O relatime=on -O dnodesize=auto \ tankB raidz2 /dev/disk/by-id/wwn-disk9 ... /dev/disk/by-id/wwn-disk16 Initial mirror copy:
# Snapshot source zfs snapshot -r tankA_old@seed zfs snapshot -r tankB_old@seed # Full send (use -Lec for large/sparse/embedded, and pv if you want progress) zfs send -LecR tankA_old@seed | zfs recv -uF tankA # -u leaves datasets unmounted for review zfs send -LecR tankB_old@seed | zfs recv -uF tankB # Review properties/mountpoints, then mount zfs mount -a Incremental catch-up right before cutover:
zfs snapshot -r tankA_old@cutover zfs snapshot -r tankB_old@cutover zfs send -LecR -I @seed tankA_old@cutover | zfs recv -F tankA zfs send -LecR -I @seed tankB_old@cutover | zfs recv -F tankB Point shares to the new pools (update Unraid Shares to include/exclude pools as you like), then export the old pools and repurpose those disks if desired.

Now with data on the system...

Standing up the cold pool on the MD3060e
Create a single cold mirror/raidz pool (e.g., cold), tuned for capacity and resiliency (often raidz2/3). Same property set as above (zstd-3, atime=off, xattr=sa, acltype=posixacl). Consider setting:

zpool set autoreplace=on cold zpool set autoexpand=on cold Monthly cold-sync workflow (no host downtime)
Setup once (recommended tooling):
Use Sanoid/Syncoid (Community Apps plugin on Unraid) or plain ZFS send/recv scripts. Syncoid is great for one-liner replications and pruning.
Make the cold pool not automount at array start in Unraid (ZFS pool settings) so the host boots cleanly with the shelf off.

Each month:
Power ON MD3060e → wait for SAS links.
On Unraid: import the pool:
zpool import zpool import cold Replicate hot → cold (examples with syncoid):
# replicate whole pools or specific datasets; --no-sync-snap if you manage snaps yourself syncoid --recursive --compress=mbuffer tankA cold/tankA syncoid --recursive --compress=mbuffer tankB cold/tankB Or raw ZFS (per dataset):
SNAP=$(date +%Y%m%d) zfs snapshot -r tankA@${SNAP} zfs snapshot -r tankB@${SNAP} zfs send -LecR -I @prev tankA@${SNAP} | zfs recv -F cold/tankA zfs send -LecR -I @prev tankB@${SNAP} | zfs recv -F cold/tankB # (Keep track of the last snapshot name per dataset; you can use bookmarks too.) Scrub the cold pool occasionally:
zpool scrub cold Export and power off:
zpool export cold # now safe to power down the MD3060e (Export first, then power the shelf off. The Unraid host stays up the whole time.)

^ -- Most can be automated!...

Share & path hygiene
Keep hot shares and cold replicas separated (e.g., /mnt/tankA/..., /mnt/tankB/... vs /mnt/cold/...).
Do not let Docker/VMs or SMB/NFS exports reference /mnt/cold/... paths (or mark those shares as Export: No in Unraid) so nothing breaks when the shelf is offline.
For SMB, you can expose read-only replicas on demand when the shelf is online.
Health & monitoring tips
Enable and review smartd on the HBAs/shelves; NetApp SAS3 shelves usually expose SMART through the expander (check that your HBA is in IT mode).
Schedule zpool status, zpool scrub, and alerting.
Consider zfs set reservation on cold datasets if you want to prevent accidental over-filling during replication.


Q/A: Direct questions:

Question: Can I stop the “array” and power off only the cold shelf?

You don’t need to stop the host or the whole Unraid array. Just:
Ensure the cold pool is not set to automount on array start.
When finished syncing: zpool export cold → power OFF the MD3060e.
When ready to sync again: power ON the MD3060e → zpool import cold → replicate → zpool export cold → power OFF.
The hot NetApp shelves and the NVMe pool keep running 24×7—minimal to zero downtime for the Unraid server and your hot storage.

...That is my understanding...

Unraid templates are stored on the flash drive.

cd /boot/config/plugins/dockerMan/templates-user/

example:
root@The-Borg:/boot/config/plugins/dockerMan/templates-user# ls
my-ApacheGuacamole.xml my-Immich_Valkey.xml my-Redis_Immich.xml my-homarr.xml my-proxmox-backup-server.xml
my-ClamAV-clamdscan.xml my-Influxdb.xml my-Redis_NetBox.xml my-homeassistant.xml my-sftp-fail2ban.xml
my-ClamAV.xml my-MakeMKV.xml my-RocketChat.xml my-iPXE-buildweb.xml my-sftp.xml
my-ClamAV.xml.bak my-MongoDB-RocketChat.xml my-UniFi-Video.xml my-immich.xml my-steam-headless.xml
my-Factorio.xml my-Palworld.xml my-UptimeKuma.xml my-mariadb-hive.xml my-syncthing.xml
my-Grafana-Unraid-Stack.xml my-Pihole-DoT-DoH.xml my-binhex-syncthing.xml my-netbootxyz.xml my-unifi-controller-reborn.xml
my-Homebox.xml my-PostgreSQL_Immich.xml my-foldingathome.xml my-netbox.xml my-watchtower.xml
my-Immich_PostgreSQL.xml my-PostgreSQL_Netbox.xml my-frigate.xml my-plex.xml
root@The-Borg:/boot/config/plugins/dockerMan/templates-user#

I can cat my-xyz template and read the xml line.
You might be able to pull the database password from that line...

Example:
root@The-Borg:/boot/config/plugins/dockerMan/templates-user# cat my-mariadb-hive.xml

<Config Name="MYSQL_PASSWORD" Target="MYSQL_PASSWORD" Default="DATABASE_PASSWORD" Mode="{3}" Description="Set this to the password you want to use for you MYSQL_USER (minimum 4 characters and non-alphanumeric passwords must be properly escaped)." Type="Variable" Display="always" Required="false" Mask="true">clonedeploy</Config>

as I did play around with hive farm os for bitcoin miners.. there default password is clonedeploy. Which is seen in the template.

This was added as a setting in v7

Settings> Console settings>



Disable Screen Blank Time.

Otherwise you need to edit the main>flash and add a append option of consoleblank=0
Main > Flash > Syslinux

better script to run tigten and double checked... Otherwise you need to change your plex account password. as plex has your account flaged...

#!/bin/bash set -euo pipefail # ========================= # Set these for your box # ========================= CONTAINER="plex" # Docker container name (linuxserver/plex) APPDATA_BASE="/mnt/user/appdata/plex" # your container's /config on host PREFS="$APPDATA_BASE/Library/Application Support/Plex Media Server/Preferences.xml" # ======= Paste fresh token from https://plex.tv/claim ======= CLAIM_TOKEN="claim-PASTE_YOUR_TOKEN_HERE" # ============================================================ # Quick validation if [[ -z "$CLAIM_TOKEN" || "$CLAIM_TOKEN" != claim-* ]]; then echo "ERROR: Set CLAIM_TOKEN to a valid value starting with 'claim-'." exit 1 fi command -v docker >/dev/null || { echo "ERROR: docker not found."; exit 1; } command -v curl >/dev/null || echo "WARN: curl not found on host; will try container." [[ -f "$PREFS" ]] || { echo "ERROR: Preferences.xml not found: $PREFS"; exit 1; } echo "==> Stopping container: ${CONTAINER}" docker stop "${CONTAINER}" >/dev/null || true # Backup Preferences.xml ts="$(date +%F_%H-%M-%S)" backup="${PREFS}.bak.${ts}" echo "==> Backing up Preferences.xml -> ${backup}" cp -f "${PREFS}" "${backup}" # Read ProcessedMachineIdentifier (nice-to-have for claim exchange) echo "==> Reading ProcessedMachineIdentifier" PMI="$(grep -o 'ProcessedMachineIdentifier=\"[^"]*\"' "${PREFS}" | cut -d'"' -f2 || true)" if [[ -z "${PMI}" ]]; then echo "WARN: No ProcessedMachineIdentifier found. We'll rely on POST /myplex/claim after start." else echo " PMI=${PMI}" fi # ---- Scrub all PlexOnline* “claimed” markers so linuxserver will accept a new claim ---- # (Per multiple reports, these four block re-claim if present.) echo "==> Removing PlexOnline* attributes (Username/Mail/Home/Token) from Preferences.xml" awk '{ gsub(/ PlexOnlineUsername="[^"]*"/,""); gsub(/ PlexOnlineMail="[^"]*"/,""); gsub(/ PlexOnlineHome="[^"]*"/,""); gsub(/ PlexOnlineToken="[^"]*"/,""); print }' "${PREFS}" > "${PREFS}.tmp" && mv "${PREFS}.tmp" "${PREFS}" # Optional: normalize ownership for Unraid echo "==> Ensuring ownership nobody:users on appdata (optional)" chown -R nobody:users "${APPDATA_BASE}" || true echo "==> Starting container: ${CONTAINER}" docker start "${CONTAINER}" >/dev/null # Wait briefly for PMS to answer /identity (up to ~30s) echo "==> Waiting for Plex to come up..." HTTP_CODE="" for i in {1..30}; do if docker exec "${CONTAINER}" sh -lc 'command -v curl >/dev/null 2>&1' 2>/dev/null; then HTTP_CODE="$(docker exec "${CONTAINER}" sh -lc \ "curl -s -o /dev/null -w '%{http_code}' http://localhost:32400/identity" || true)" else HOSTPORT="$(docker inspect --format='{{ (index (index .NetworkSettings.Ports "32400/tcp") 0).HostPort }}' "${CONTAINER}" 2>/dev/null || true)" [[ -z "$HOSTPORT" || "$HOSTPORT" == "<no value>" ]] && HOSTPORT="32400" command -v curl >/dev/null && HTTP_CODE="$(curl -s -o /dev/null -w '%{http_code}' "http://127.0.0.1:${HOSTPORT}/identity" || true)" || HTTP_CODE="" fi [[ "$HTTP_CODE" == "200" ]] && { echo " Plex is responding."; break; } sleep 1 [[ $i -eq 30 ]] && echo "WARN: Plex /identity not responding yet; continuing anyway." done # --------------------------------------------- # Path A (preferred if PMI is present): exchange claim->auth token, seed back into Preferences.xml # --------------------------------------------- did_exchange=0 if [[ -n "${PMI}" ]]; then echo "==> Exchanging claim token with plex.tv (using PMI)" AUTH_TOKEN="$(curl -fsSL -H "X-Plex-Client-Identifier: ${PMI}" \ "https://plex.tv/api/claim/exchange?token=${CLAIM_TOKEN}" \ | sed -n 's:.*<auth_token>\([^<]*\)</auth_token>.*:\1:p' || true)" if [[ -n "${AUTH_TOKEN}" ]]; then echo " Got auth token (hidden). Seeding into Preferences.xml..." # Stop again momentarily to avoid write races docker stop "${CONTAINER}" >/dev/null || true awk -v tok="${AUTH_TOKEN}" '{ # Add PlexOnlineToken before the closing "/>" of the root element if absent if ($0 ~ /PlexOnlineToken="/) { gsub(/ PlexOnlineToken="[^"]*"/, " PlexOnlineToken=\"" tok "\"") } else { sub(/\/>$/, " PlexOnlineToken=\"" tok "\"/>") } print }' "${PREFS}" > "${PREFS}.tmp" && mv "${PREFS}.tmp" "${PREFS}" docker start "${CONTAINER}" >/dev/null did_exchange=1 else echo "WARN: Claim exchange failed (token expired or PMI mismatch). Will try POST /myplex/claim." fi fi # --------------------------------------------- # Path B: always give Plex a local “nudge” to claim # --------------------------------------------- echo "==> POSTing claim token to local /myplex/claim as final nudge" CLAIM_HTTP=0 if docker exec "${CONTAINER}" sh -lc 'command -v curl >/dev/null 2>&1' 2>/dev/null; then CLAIM_HTTP="$(docker exec "${CONTAINER}" sh -lc \ "curl -s -o /dev/null -w '%{http_code}' -X POST 'http://localhost:32400/myplex/claim?token=${CLAIM_TOKEN}'" || true)" else HOSTPORT="$(docker inspect --format='{{ (index (index .NetworkSettings.Ports "32400/tcp") 0).HostPort }}' "${CONTAINER}" 2>/dev/null || true)" [[ -z "$HOSTPORT" || "$HOSTPORT" == "<no value>" ]] && HOSTPORT="32400" if command -v curl >/dev/null; then CLAIM_HTTP="$(curl -s -o /dev/null -w '%{http_code}' -X POST "http://127.0.0.1:${HOSTPORT}/myplex/claim?token=${CLAIM_TOKEN}" || true)" else echo "WARN: No curl in container or host; skipping local POST." fi fi echo " Claim POST returned HTTP ${CLAIM_HTTP} (200/201/204 are fine; 4xx means expired claim)." echo "==> Done." echo "Open: http://<UNRAID-IP>:32400/web -> Settings -> General" echo "You should see the server signed in and claimed." echo "Backup kept at: ${backup}" stop Plex and back up Preferences.xml
scrub all the “claimed” markers that block re-claim on linuxserver.io images (the PlexOnline* attributes), then either (a) inject a fresh long-lived token via the claim-exchange flow or (b) simply POST your claim-... to the local /myplex/claim endpoint as a fallback nudge.
FYI, folks running the linuxserver image consistently report they had to clear all of these before a new claim would “take”: PlexOnlineUsername, PlexOnlineMail, PlexOnlineHome, and PlexOnlineToken—not just the claim token. Many also succeed by just POSTing the claim token to /myplex/claim after clearing those keys... whcih is what this script will do above...

What changed / why it’s robust
Scrubs all four PlexOnline* attributes before trying anything, which avoids the “server already claimed” dead-end the linuxserver image hits when these remain populated...
If we have a ProcessedMachineIdentifier, we do the official claim-exchange and inject a long-lived auth_token into PlexOnlineToken. This mirrors the documented “manual claim” flow people follow with X-Plex-Client-Identifier headers.
Regardless, we also POST your claim-... to http://localhost:32400/myplex/claim, which multiple Unraid users reported as the simplest reliable nudge after a password reset
Graceful fallbacks if curl isn’t in the container or host, and safe backups with timestamps.

https://trash-guides.info/File-and-Folder-Structure/How-to-set-up/Unraid/

https://trash-guides.info/File-and-Folder-Structure/

only with using a Microsoft account app password.

https://support.microsoft.com/en-us/account-billing/how-to-get-and-use-app-passwords-5896ed9b-4263-e681-128a-a6f2979a7944

Your symptoms line up with two classic gotchas on Unraid:
you have two L3 interfaces in the same /24 (192.168.42.0/24), so Linux will pick the “wrong” egress sometimes (policy routing needed if you insist on this), and
host ↔ macvlan/ipvlan access quirks when you try to reach containers/VMs living on VLAN bridges from the host.
Below is a clean, repeatable layout that fixes both and matches your goal: eth0 only for Unraid GUI, eth1 for services on VLANs 1,10,20.


(Potental fix - action order)
Give br0/eth0 the only IP in 192.168.42.0/24 (192.168.42.100/24 gw .1).
Put br1.1, br1.10, br1.20 → IPv4 None (no gateways).
On the switch, make eth1 a trunk with VLANs 1/10/20 to your router.
Use ipvlan docker networks bound to br1.1 / br1.10 / br1.20 with the proper subnets/gateways.
(Optional) If the host must reach those VLANs directly, use the small shim + ip rule script above.
That’ll give you: GUI only on 192.168.42.100 (eth0), and containers/VMs cleanly reachable on eth1 VLANs without iproute fights.

Switch / Router (make sure first)
The switch port for eth1 is a trunk/tagged port carrying VLAN 1,10,20 (VLAN 1 can be native/untagged or tagged; just be consistent with Unraid).
Your router has SVIs / gateways:
VLAN 1 → 192.168.42.1/24
VLAN 10 → 192.168.20.1/24
(and VLAN 20 → whatever you plan, e.g. 192.168.30.1/24)

Unraid – Network Settings (stable “one L3 per subnet” design)
Goal: Only br0 (eth0) holds an IP in 192.168.42.0/24 for management. The service VLANs live on br1 VLANs with no IPs on the host—so the kernel won’t fight you on routes.
eth0
IPv4: Static 192.168.42.100/24
Gateway: 192.168.42.1
Bridging: Yes (br0)
VLANs on br0: No
eth1
IPv4: None
Bridging: Yes (this creates br1)
VLANs on br1: Yes
br1.1 (VLAN 1) → IPv4 None (do not give the host an IP here)
br1.10 (VLAN 10) → IPv4 None
br1.20 (VLAN 20) → IPv4 None
No gateway on br1 or any br1.x
This makes Unraid itself reachable only at 192.168.42.100 via eth0/br0, and it keeps the kernel from creating competing routes for the same /24 on br1.1.

Docker – use IPvlan and pin each VLAN to its parent
Using ipvlan avoids the macvlan host-call-trace mess and is simple for L3 separation.

In Settings ▸ Docker:
Docker custom network type: ipvlan
Parent interface for custom networks: choose none here (we’ll create per-VLAN networks manually), or set one then override with -o parent below.
# VLAN 1 (containers in 192.168.42.0/24 on br1.1) docker network create -d ipvlan \ --subnet=192.168.42.0/24 --gateway=192.168.42.1 \ -o parent=br1.1 pub42 # VLAN 10 (containers in 192.168.20.0/24 on br1.10) docker network create -d ipvlan \ --subnet=192.168.20.0/24 --gateway=192.168.20.1 \ -o parent=br1.10 pub20 # VLAN 20 (example) docker network create -d ipvlan \ --subnet=192.168.30.0/24 --gateway=192.168.30.1 \ -o parent=br1.20 pub30
*Attach each container to the correct network (pub42, pub20, pub30).
From other LAN clients, you’ll reach them normally through your router (SVIs).

VMs – attach to br1 VLANs
For VMs that should live on VLAN 10 and 20:
Add a virtio NIC and select br1.10 or br1.20 as the bridge.
Configure the VM’s guest IP/gateway inside the VM (e.g., 192.168.20.x with gw 192.168.20.1).
Host container/VM access (optional, from Unraid shell itself)
Because the host (192.168.42.100 on br0) is not on br1.1 anymore, the kernel won’t “hairpin” traffic for you. If you want Unraid itself to reach containers on those VLANs:
Option A (recommended): Let routing do it—your router already has the VLAN SVIs. The host will hit 192.168.42.1 and the router forwards to the container subnets. No extra config needed.
Option B (direct shim on the VLAN): Add a tiny “shim” IP on each VLAN using a macvlan/ipvlan sub-iface plus policy routing so replies go back out the same VLAN. Here’s a single-VLAN example for VLAN 10; adapt for others as needed:

*Recommend / minor ip rule route fixes

#!/usr/bin/env bash set -euo pipefail PARENT="br1.10" # the VLAN bridge SHIM="mac10" # shim iface name SHIM_IP="192.168.20.10/24" # a free IP in VLAN 10 just for the host GW="192.168.20.1" TABLE="110" # Create shim if missing ip link show "$SHIM" &>/dev/null || ip link add "$SHIM" link "$PARENT" type macvlan mode bridge ip addr show dev "$SHIM" | grep -q "${SHIM_IP%%/*}" || ip addr add "$SHIM_IP" dev "$SHIM" ip link set "$SHIM" up # policy routing: packets FROM the shim IP use table 110 via the shim ip rule del pref 10110 2>/dev/null || true ip rule add from ${SHIM_IP%%/*}/32 table ${TABLE} pref 10110 ip route flush table ${TABLE} ip route add 192.168.20.0/24 dev ${SHIM} table ${TABLE} ip route add default via ${GW} dev ${SHIM} table ${TABLE} # rp_filter relaxed to allow asymmetric return if needed sysctl -w net.ipv4.conf.${SHIM}.rp_filter=2 >/dev/null
Now the host can curl 192.168.20.x using source 192.168.20.10 and replies will return the same path.


Explanation:Why you could reach 192.168.42.10 but not br1.10
With br1.1 (VLAN 1) in the same /24 as br0 you created an ambiguous ARP/routing situation; sometimes it works, sometimes it hairpins the wrong bridge.
For br1.10, if the bridge exists but the host has no L3 route (no IP) and the switch port isn’t trunking VLAN 10, you’ll see exactly “containers unreachable.” The above layout fixes both: L2 present (trunk), L3 via router, and no duplicate subnets on the host.
Sanity - Quick health checklist
Run these from the Unraid shell after applying:
# The host should have exactly ONE default route via br0/eth0 ip -4 route # You should NOT see a host route for 192.168.42.0/24 via br1.1 # (only via br0). VLAN 10/20 shouldn't appear unless you added shims. # Docker networks bound to right parents: docker network ls docker network inspect pub42 | grep Parent docker network inspect pub20 | grep Parent # A container on VLAN 10 should ARP its gateway on br1.10: # (replace veth name as needed) bridge link | grep br1.10
If still stuck, grab and share plese:

ip -4 a
ip -4 route
ip rule show
docker network inspect pub42 pub20

ok what do you want it to do and how do you want to interact with it?

If i'm reading your post coretly...

Your Current Layout
2× NVMe → Main Cache Pool (System / Appdata)
Good choice: NVMe is fast, perfect for Docker/VM/appdata workloads.
⚠️ Consider mirroring them (RAID1) if you want protection. Appdata can be backed up, but losing it is painful.
1× 2TB SSD → Cache Pool (no protection) for Media (with Mover to Array)
Reasonable if you’re only using this as a write cache for large media downloads.
⚠️ Risk: no redundancy, if the SSD dies mid-transfer before mover runs, you lose files.
2× 2TB SSD → RAID1 Cache Pool (Databases + Immich)
Excellent use. These workloads are I/O heavy and benefit from protection.

Some limitation to review:
Use Cases & Considerations
Media (TV, Movies, etc.)
Long-term storage belongs on the array (your 5×15TB HDDs).
Cache for downloads is fine, just know unprotected SSD cache has risk.
Suggestion: you could combine all 3 SSDs into one BTRFS pool and assign share rules per use-case. That way you’re not slicing up your SSDs too much.

Nextcloud / Alternatives
Nextcloud is powerful but heavy and finicky (lots of PHP, DB overhead, maintenance, and problems with updates).
Alternatives:
Immich (already planning): stellar for photos.
Seafile: lightweight document sync/collaboration, much faster than Nextcloud.
Syncthing: if you only need file sync, no groupware.
If you don’t need calendars/email: skip Nextcloud.
sftp for file webdav access or even rejetto hfs...
What is nextcloud going to provide that is better or easeir done with something else?
since your using immich there is nexcloud with memories pluin as example....
Databases / Password App / Paperless / Dev Work
Absolutely best to keep on SSD (mirrored).
If you later expand, consider moving them to NVMe for even more speed.
Light Game Server
SSD/NVMe is perfect for game servers.

Your asking alot out of the hardware. immich and a game server can be quite resource intensive...

GIvein the info:

Share Layout (Media / Photos / Apps)
You asked whether to merge or split shares:
Option 1 (Keep Separate):
Media share on HDD array (with SSD write cache).
Photos share on RAID1 SSD pool for Immich.
Cleaner isolation, but more pools = more complexity.
Option 2 (Merge SSDs into one big protected pool):
One larger SSD RAID1 pool (~2TB usable).
Appdata, Photos, Databases all live there.
Simpler, but less flexibility.
I’d recommend Option 2 for simplicity, unless you specifically want to dedicate an SSD to staging downloads.
or look into zfs and other disk options...

Recommendations:
Mirror NVMe pool (RAID1) → safer for appdata, VMs, configs.
Combine 3× SSDs into 1 RAID1 pool (BTRFS/ZFS mirror) and then split workloads by share.
I recomend a raidz1 to get the mirro and strip protection from zfs file format...
Use “Prefer Cache” for databases, photos, appdata.
Use “Yes → Mover” for downloads/media staging.
Keep HDD array (5×15TB) as bulk storage → parity protection for media library.
Skip Nextcloud unless you need groupware → try Seafile (lightweight) or just Immich + Syncthing.

ok no worries. I assume your using this CA template the:
the above is example as the tempate essential builds a docker run line



you may need to click the advance togle at the top right some setting and options are only avliable with that togle


so in the above docker run shared. I gave exampels not direct paths.

the bare mini as well.
so the data folder should be located to /mnt/user/T_Media/Torrent/ unless you set its path


and the config folder path doesn't exist in the current CA template

even with the advance toggle and show more settings.

I was pulling data form there docker hub / git hub.

The have adatioal support forum found here
https://forums.unraid.net/topic/60143-support-clowryms-docker-repository/

the template is also using the dev tag


github:
GitHub
GitHub - haugene/docker-transmission-openvpn: Docker cont...
Docker container running Transmission torrent client with WebUI over an OpenVPN tunnel - haugene/docker-transmission-openvpnDocker hub:
https://hub.docker.com/r/haugene/transmission-openvpn/

so without it int he tempalte its inside teh docer via termail cd /config
/your/config/path/:/config \

you will have to edit the repositry to a named tag
and add that path:
as ths is the latest image:
sha256:ecc30da79114d801295fd10a5dbaf8640b19707d012fb55be0671ddbe0503037
haugene/transmission-openvpn:latest

Please post a diag file. Your docker vdisk may be full. or an existing docker layer exist and is breaking the docker download.

Docker Guides:
Immich Docker-compose Setup
Immich Unraid-Template in the CA

I would recommend running the docker prune and cleanup scripts. as you may have deleted the docker but not the image.
https://forums.unraid.net/topic/178033-bmartino1-user-scripts/#findComment-1478647

also that docker may not be pulling the correct docker as its taged for latest. try docker pul the current lates build first, then build immich...

docker pull imagegenius/immich:v1.143.1-ig424
https://github.com/imagegenius/docker-immich/releases/tag/v1.143.1-ig424