mikescott

Figured this out for anyone having a port binding conflict in future with tailscale hook and a container both listening on 443. Despite me changing the port mapping variable, you have to toggle on Advanced View and also update the Web UI: https://[IP]:[PORT:8443] part as well. Once I did this, everything worked. I guess this was first container I've had to change the port mapping on, so I thought the Web UI path under Advanced View would have updated automatically to match the WebUI port mapping configured in the template, but it does not. Lesson learned.

Running into a Tailscale hook issue. When running tailscale within the container, I'm getting a 0.0.0.0:443 bind error; 443 in use. in the nextcloud container logs. I assume this is because both Tailscale Serve and Nextcloud are using this internal port mapping. I cannot change the internal port of Nextcloud (443). I tried changing the Tailscale Serve Port to 8443, but the same issue persisted. I can get it to work by changing the Tailscale Serve Protocol Port to 80 (default is 443); but then you get the http warnings, which defeats the purpose of a tailscale serve DNS address I'd think. What is my best solution to get this working properly with Tailscale sidecar/hook. (I have other containers successfully deployed using tailscale hook, but none of them run a default internal port 443)

Thank you for your response. Ya, I'd like to avoid running as root if possible. Just curious why joplin requires this, or throws this error, while others have no issue with the tailscale hook without root permission.

Couple things to try and look out for: 1) if you toggle advance view, do you have any delays on your containers? If you do, start all, to my knowledge, will respect these delays while a manual start of the containers one-by-one won't. So the Start All might just take a smidge longer with the delays in there. 2) if you don't have any delays, but have containers that depend on another, add delays. That is, you have an app that depends on a postgres database. Starting all at once might not work without a delay on the database as the app and database will start at the same time and app will fail to find database. Add 10s delay to database and make sure the order of listing is correct (app container below database container). Database will start, countdown 10s then proceed to next container on your list (or that is my interpretation of how delay works based on logs). Ensures your database is ready to accept connection before your app starts. Manually starting your containers one by one would circumvent this problem as all containers are not attempting to start up at once. 3) if none of the above applies to you, after you click Start All, refresh page after 15s or so, sometime just the WebUI needs a refresh to show that everything actually has started.

Glad to hear it :) Remember to copy the header backups somewhere outside/off your physical server, and to make additional header backups of new drives added to the array down the road (each drive has their own header). While one passphrase (aka. key) unlocks all the drives in your array (aka. your vault) in unRAID, each drive has a different header (aka. lock).

Improved native LUKS encryption features and/or documentation. Encryption is often an avenue myself, and others here, employ if we look to avoid data access either through physical theft of drives/device, or some like it for better peace of mind during an RMA process. While I realize that across the Linux universe, LUKS is a feature offered for your drives, and beyond that you are left on your own to figure the rest out. However, in an effort to make the unRAID system more accessible to more users I think there could be a gradual improvement around the information and handling of LUKS 1) Enhance the documentation around LUKS. The current page on encryption only covers the process of enabling LUKS additional information or precautionary notes on what LUKS Headers are, and the importance of backing them up ability to add additional keys/keyfiles while this is "simple" on other Linux desktops/laptops where you point to individual drives and luksAddKey; I am still not sure if I can manually iterate through each drive on the array via terminal with luksAddKey, and then the whole array would startup under this new key. I would continue to suggest adding documentation around how to backup, restore, and how unRAID itself manages the header offsets etc; but this leads into 2) 2) WebUI for LUKS Management in an effort to make encryption more accessible, offering native UI support for adding keys, backing up headers, restoring headers, etc. would be massive. I documented my recent learning and experimentation process in a post here. While it worked, I don't know if I did it the "unRAID way". That is, I now believe my Step 9 technically wrote over some upfront unRAID metadata, which maybe precedes the LUKS header on the raw partition sdxX, which necessitate Step 9 and 10. To avoid that, I know I would have to target the mdXpX device path, but you can only do that once the array is started, which you can't if a header is corrupted (to my knowledge anyways; maybe you can in Maintenance mode and I missed it?) I wish I had a test server to continue experimenting with LUKS on unRAID, but I don't, and my server is up and running and has data on it. So, while I experimented to make sure I know enough around LUKS headers and restoring them before proceeding with my unRAID server, the value of having some official documentation on it and even some UI management cannot be overstated. Loving unRAID so far. Keep it up guys. Love the Uncast Show as well. Just thought I would drop my two cents (or whatever they are worth) as a new user to unRAID. <3

Thank you for the reply and information! I did the backup and download, but then went digging into the tags, and I think I got lucky! I intentionally haven't updated my nightly instance in about a week, and I saw this below (as of today Apr 18, 2026). The latest tag was pushed to 3.16.0 and was published very recently; meaning the latest tag is now newer than my non-updated nightly package. I was able to simply stop the container > change tag to latest > spun up again successfully....doing this it was like updating the image. I think the issue exists if your nightly is newer than the latest

Dropping in here to say a HUGE thank you to @bmartino1 . I love the more "best-practice" route with the valkey, and posting that tag link (without it, I wouldn't have seen and questioned all the tag types) For anyone dropping here in near future for fresh installs, I have successfully run all three docker containers immich_valkey immich_postgresql and immich (previously was just the immich_postgresql and immich with internal Bitnami Redis). Because my immich is a fresh install, my postgres is using ghcr.io/immich-app/postgres:16-vectorchord0.5.3 (as of the date posting this, check the tags link originally posted by bmartino1 for latest when you are viewing this); no need for hybrid pgvecto-vectorchord hybrid image tags on fresh installs. Also thank you @MowMdown for confirming my thoughts around the tags. UPDATE: I actually opted to run 8.0-trixie for Immich_Valkey, currently the CA default is 8.0.6. But, I coincidentally noticed that there was a CVE security patch applied to major Valkey versions (8 & 9), this was applied in 8.0.7, but instead of me having to manually update the small patch numbers, i kept the major version the same, but allowed for minor patch upgrades, e.g. security patches 8.0-trixie

dropping in here to say THANK YOU. My tailscale hook was hanging....came looking to find if I can manually make directory. Thank you!

this is great! thank you. Just setup my immich (no data in it yet); but I think I might redo some things remove the internal redis and run the Immich_Valkey instead AND since its a fresh install for me, I think I realized I can just run 16-vectorchord0.5.3 (thank you VERY much for that link to tags in your post). I did some reading and it seems those long vectorchord-pgvector tags are for people with existing setups to bridge the upgrade from pgvector to vectorchord in vector databasing? But because I'm starting out, I should just go for vectorchord only maybe

I wonder if it is because the nightly you were on was newer than the latest. That is, maybe switching to latest actually downgraded you. I'm thinking to wait when latest surpasses the nightly, but I'm not sure where the best place to check the versions getting pushed under each tag for the official mealie would be. This way the tag change will be like a normal update....not sure if this is correct line of thinking. When you say backup and download the recipe database; are you referring to some internal Mealie backup feature, or a postgreSQL backup?

I've recently installed this docker container and also noticed it was still on the nightly tag. Can I easily change it to latest now?

Addendum A My continued pursuit to better understand LUKS and drive management with unRAID has continued, and I think I have gained additional understanding how the drives and headers work. But, I would love feedback from the more experienced people in here; there is no official documentation outlining what I am discussing here (which is why I am documenting it here), I am just testing and troubleshooting to understand the system more; and sharing here for continued reference and, hopefully, feedback. My understanding now of the bytes on the drive in its different states are as follows (we will use the raw partition sdb1 and the mapped unRAID managed partition md1p1 as an example) Array is stopped: md1p1 does not exist and we will only see sdb1 in this "raw" partition state I believe the data on the drives starts like this: | unRAID metadata ---- | LUKS header ---- | your actual data --------------------- | we can run cryptsetup luksDump /dev/sdb1 for header information Array running (maintenance or normal): the drive is now mapped to unRAID managed partition md1p1 in this unRAID managed partition state, the first parts of the data on the drive now start with the LUKS header: | LUKS header ---- | your actual data --------------------- | we can run cryptsetup luksDump /dev/md1p1 for header information (targeting sdb1 now will not work) Above I backed up the header from unRAID managed md1p1 (which is good) and successfully restored to raw partition sdb1; while this worked, I now wonder if this is the reason for Step 9 necessitated above. I wrote over the unRAID metadata (I think several KB), with the header restore and the refresh was needed for unRAID to add its metadata back to the beginning of the drive, and obviously invalidating our Parity requiring a check and correction. This leaves me with the thought that the Gold Standard for header restore would be to obviously restore to md1p1 , and this makes sense. The only question I have, to which I do not have an answer yet (haven't tested and can't remember during my original test-run), is if it was possible to start the Array in Maintenance mode with an unmountable drive in the array (remember it shows as unmountable bc the header was corrupted (intentionally for testing)). I'm fairly confident the Start button was greyed out, but don't recall if I tried toggling Maintenance Mode on or not, and if I did, would the Start button become available to select? Would love input on the ability of starting Array in maintenance mode with unmountable drives in array. If this is not possible, then I am left to assume the header backup from md1p1 and restoring to the raw sdb1 is the only "plan of action" for restoring your headers.

I am curious about this as well. I am running an encrypted array and set it up with a passphrase, but would like to add a keyfile as well now. LUKS typically has a keyfile or passphrase for each drive you encrypt, makes sense. When you want to add another passphrase or keyfile on the drive, you simply use luksAddKey via terminal. However, because unRAID uses the one passphrase for all the drives in your encrypted array (you don't make a new one each time you add a new encrypted drive); When you unlock the array upon boot, the one passphrase unlocks all drives at once (not sure if unraid just runs LUKS encryption and uses existing passphrase in backend) To add a keyfile to one of the remaining keyslots on the headers (0 being used by my passphrase), I can use luksAddKey, BUT when I do this do I simply point the command to the same keyfile for each drive? That is, do I: make the random keyfile iterate through each drive in my array runningcryptsetup luksAddKey command via terminal pointing to the same keyfile each time? will this keyfile now unlock the entire array at once after a boot? P.S. @acid2000 I did some work and understand LUKS backup and restore and shared it here https://forums.unraid.net/topic/198159-a-walkthrough-my-luks-header-backup-corruption-and-restore/

unRAID OS: 7.3.0-beta2 docker container: Joplin New to unRAID, but had success deploying tailscale within Mealie and getting certificate via TS Serve. It was cool. Mealie being PWA, https in browser enables some features, so this was very helpful. Was hoping to do all my docker services to be shared this way, but running into a snag on my second docker container deployment, Joplin. I get the following error in logs after running: Executing Unraid Docker Hook for Tailscale ERROR: No root privileges! ERROR: Unraid Docker Hook script throw an error! Starting container without Tailscale! Starting container... My Joplin works fine, and do it the original way, point it at Tailscale IP of server, and in ACLs allow port 22300 access. I guess https isn't required for Joplin so not a huge issue; but alas I was hoping to have all my dockers as a device on tailnet that I just run with tags; but I guess when I get to spinning up Plex again, I'll have to share out my server with port ACLs on it anyways? Curious for peoples' feedback on tailscale deployment in the container and getting certificate via serve, vs running the "old-school" way and having port ACLs/Grants on your server in tailscale. Thank you!

8GB. I upgraded from Synology running 2GB. My money went to hard drives and server. Until I show myself that I will get close to saturating the RAM with dockers, I'll increase RAM then. Might get closer than I think with my self-hosting has increased rapidly in last 2 years.

Not sure if you've figured this out yet, just came across your post. If I understand your question correctly you've found the Joplin "app" but can't find server/databas? Joplin uses postgres (specifically tag:16). Find postgres16 and use that as joplin db.

I am making this post, because I started my adventure in unRAID and wanting to run LUKS encrypted drives. As a result, I wanted to be confident with LUKS management; but, the information I researched on LUKS on unRAID was scattered, non-existent, or outdated. Before putting data onto an encrypted drive, I made it my mission to understand LUKS and managing the headers in case of corruption. I could not find a nice summary/guide to achieve the following within unRAID: Backup a LUKS Header (Steps 1-5) Intentionally corrupt the Header (this was conducted for testing; do not perform under normal operation) Restore the LUKS Header (Steps 6-10) My goals with this post is to hopefully provide a guide or reference to individuals in the community that are at a point like me, and to receive feedback from those more experienced to further refine this process for myself and others. I documented my steps running through a backup/corruption/restore process for replication and sharing. For understanding unRAID partitions and labels see unRAID Data Recovery Docs. Quick summary table below: Label Typical path Usage Parity protected? Disk 7 /mnt/disk7 Unraid mount point Yes (if array disk) Array partition /dev/md7p1 Unraid-managed device Yes Raw partition /dev/sdj1 Direct device access No For array drives, always use the Unraid-managed device (such as /dev/md5p1) to preserve parity protection Using the raw partition (e.g. /dev/sdj1) will not update parity, leaving it invalid THE INTENTIONAL HEADER CORRUPTION AND RESTORE WAS CONDUCTED ON MY NEW SERVER WITHOUT ANY DATA ON IT MAKE DATA BACKUPS. YOU ARE RESPONSIBLE FOR YOUR DATA Unraid OS 7.3.0-beta2 Below is an actual run through after having one 12TB drive formatted to xfs-encrypted. Array started in Maintenance Mode in this mode the md (unRAID-managed) driver is active allows me to read/write header while simultaneously updating parity (I want this to simulate header corruption with a running array and, therefore, parity updating with the corruption) lsblk # outputs NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 731M 1 loop /usr loop1 7:1 0 299M 1 loop /lib/firmware sda 8:0 0 10.9T 0 disk └─sda1 8:1 0 10.9T 0 part sdb 8:16 0 10.9T 0 disk └─sdb1 8:17 0 10.9T 0 part md1p1 9:1 0 10.9T 0 md └─md1p1 251:0 0 10.9T 0 crypt # here cryptsetup luksDump /dev/md1p1 # outputs LUKS header information and keyslots in use.confirms you're looking at correct md unRAID-managed device with a LUKS header mkdir -p /boot/config/luks_backups # making a folder on boot drive to save my LUKS header backup file (this will also get copied offiste) NOTE: I use Serial Number of HDD to ensure the matching of backup files to the physical device. (I am not sure what name persists in unRAID if I physically move drives around, so I used the serial no.) For this example I've replaced my S/N with WD-a1a1a1; but wherever you see this, replace with the Serial Number of your drive. cryptsetup luksHeaderBackup /dev/md1p1 --header-backup-file /boot/config/luks_backups/WD-a1a1a1_header.imgnaming the backup header file like this ensure you know which drive it belongs to verify UUID of the backup file and the header of the drive cryptsetup luksUUID /dev/md1p1 cryptsetup luksUUID /boot/config/luks_backups/WD-a1a1a1_header.imgUUIDs should match the following Bash command is just during testing to simulate LUKS corruption; DO NOT DO DURING NORMAL BACKUP AND/OR RESTORE PROCESS dd if=/dev/zero of=/dev/md1p1 bs=1M count=10 # writes 10 MB of 0s to the start of the drive ! THIS WILL BREAK THE HEADER ! # LUKS version 2 (you can see this in luksDump) headers are 16 MB so writing 10 MB will wipe out header without touching data beyond the header cryptsetup luksDump /dev/md1p1 # tests the header is "corrupted"; it will output "not a valid LUKS header" To simulate a server with a corrupted header on an Array that hasn't started up; I stopped the Array that was running in Maintenance mode. once stopped, you cannot start the Array again without formatting the drive with a new passphrase; DO NOT DO THIS IF YOU KNOW YOU HAVE DATA ON THE DRIVE AS IT WILL BE ERASED you will see a yellow padlock next to drive and show that it will be encrypted once formatted (it will say its unmountable). Our drive is already encrypted, just unRAID doesn't think it is because the header is corrupted DO NOT START ARRAY AT THIS POINT; DO NOT FORMAT THE DRIVE take note of the Serial No. of the drive to be restored (WD-a1a1a1 in this test case) with the unRAID array not started, md device no longer exists and we will now be targeting the "raw partition" atsdbX ls -l /dev/disk/by-id/ | grep [SERIAL] # outputs lrwxrwxrwx 1 root root 9 Apr 6 14:57 ata-WD-a1a1a1 -> ../../sdb lrwxrwxrwx 1 root root 10 Apr 6 14:57 ata-WD-a1a1a1-part1 -> ../../sdb1 #find the serial device that matches and note the raw partitionsdb1 in this case cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file /boot/config/luks_backups/WD-a1a1a1_header.img # confirm with an uppercase YEScryptsetup luksDump /dev/sdb1 # should output the LUKS header information now that it's restored :) Refresh Main page on WebGUI (see Addendum A below) the server will still show the same issue as before; unRAID still doesn't know the drive is encrypted and wants to format it (it shows as unmountable)...DON'T DO IT even though the physical bits on the platter are now correct, the unRAID management layer is still holding onto the "Error" status from when it last polled the drive and found it broken. It needs to re-scan the partition table and see the valid LUKS signature you just restored. The "Force Rescan" Go to the Main tab. Change the Slot 1 assignment to "None" (or whatever slot #) Wait 2 seconds. Change the Slot 1 assignment back to your Physical Drive Serial. Check the UI: should now see that unRAID detects the device as an encrypted drive (green padlock) Start the Array up :) IMPORTANT PARITY STEP because we intentionally corrupted the LUKS header (by writing 0s over it) while targeting the unRAID-managed device path md1p1 to simulate real-world corruption in a parity running array, these 0s updated on the parity disk as well THEN, we restored the LUKS header to the device partition (non unRAID-managed) at sdb1. Because of this, PARITY WILL BE INVALID (would detect on next Parity Check, but don't wait for next scheduled check) manually initiate and Parity Check with "write corrections to parity" enabled because we wrote over the first 10MB of zeros it shows 2556 errors corrected (from my Googling, this seems to line up(ish) with the 10 MB of zeros we wrote over the header and with 4096 Byte stripes on parity; 10 MB / 4096 bytes = 2560 error sectors)

Okay thank you for clarifying this. It seems my newbish interpretation continuously read that as: once you pre-clear, do not format the disk. But the timing of the disk being in the array is the key point here. Once you assign the disks > start up the array > now you can safely format disks as per prompts. As I understand it now, the docs are stating once you pre-clear don't manually format the disk before adding to array. (apologies, getting used to terminology here in unRAID, and I guess Linux in general as I transition away from Windows...starting array vs starting array AND mounting, etc)....so thanks again; I've been enjoying my reading on everything Linux (and LUKS + headers for encrypted drive management)

Going to embark on a pre-clear of two new drives and looking for clarification on the Unraid Documentation regarding adding these drives to the array after the preclear is complete. In the Unraid Docs it says "Avoid formatting a pre-cleared disk before including it in the array, as this removes the clearance signature." However, from my readings, this drive will be flagged as unmountable and require format before adding to array (I assume this is also required to add a filesystem to the drive). I know this post on unRAID forums is old; but the suggestion was to just, yes, format it. But I'm assuming and hoping things have changed since then. I'm a bit confused on what to do after pre-clear to add an xfs-encrypted filesystem to the drive and then adding it to the array. Hoping to get some clarification before I initiate the long pre-clear process. Thank you in advance.

Joining in on this conversation as I transition from Synology to unRAID and intend to use Synology as off-site backup. @Poprin thank you for this suggestion and workflow! In yours, or anyone's experience, is there a difference in restoring from ABB_multi-version, vs ABB_mirror with Snapshots? Additionally, for those looking to encrypt and compress these backups via ABB, I came across this post here How To Create Encrypted Backups. Essentially, it seems the default ABB folder that gets created is not available for encryption or compression via ABB application (odd). So the guide is a simple walk-through of creating a new shared folder (e.g. "activebackup_encrypted"), skip the built in shared folder encryption and checks within the folder creation wizard. Give system ABB application access to this new shared folder. NOW when you create a backup task, this new, non-default, folder is available for encryption and compression. I have yet to implement as I am still waiting on some HDD to spin up my new unRAID server, just doing my homework for now and thought I'd check in here and pass along

Hey everyone, joining in this conversation as I transition to unRAID here in 2026. I would feel better about running encrypted drives, and understand the necessity of backing up the data; but like many of you, would like to also back up LUKS header for easier restore. Couple questions about LUKS within unRAID first, with a failing drive in a parity protected xfs-encrypted array, a drive swap as normal can restore data (assuming 1 drive in a 1 parity protected array). Restoring of LUKS Header is specifically if you notice your passphrase no longer unlocks drives, but SMART results show drive is healthy, therefore, we assume LUKS header corruption, correct? I do agree that because unRAID offers encryption, there should be a more "baked-in" easier way of backing up and restoring LUKS Headers, alas, I'm new here so looking to learn how to get this done from you fine folks. Based on what Opawesome mentioning, sounds like dev paths line up with what docs mention here for data recovery in unRAID. "Always use /dev/mdXp1 for array drives to maintain valid parity." Okay. Based on what @polakkenak mentioned, you were able to successfully backup headers of all parity protected drives (including parity drive)? Were you able to restore? So, where are we at in unRAID 7.* for backing up and restorings LUKS Headers cryptsetup luksHeaderBackup <device> --header-backup-file <file> cryptsetup luksHeaderRestore <device> --header-backup-file <file> Will these terminal commands get the job done (I assume both backup and restore is with the array stopped)? I'm looking to do a LUKS Header backup, delete, and restore on a drive before putting data on it to show myself I'm competent enough to run an encrypted array heh. Any up-to-date help is greatly appreciated!

Thank you JorgeB, I'll look more into it, and inquire more in original thread. That's my fault; I've come from forums where I see a post that old and assume its been archived or locked, and didn't take time to look properly. Apologies.

Transitioning from Synology to unRAID, and I think I'm almost fully decided on running xfs-encrypted arrary. I figure photos, joplin, paperless-ngx...for me it's more against physical theft and I guess a bit for RMA, as some have pointed out. I know if someone broke into my place, I might have bigger things to worry about, but if they stole my hard drives, at least easily accessing the data on them isn't one thing I have to worry about. However, I am aware of what this implies and I am trying to get my ducks in a row before setting up my array; and then testing it before putting any data on it. I will be doing offsite backups to my old Synology device for data, and the LUKS encryption key can be stored within a bitwarden; additionally, did some more reading and it would be prudent to also backup the LUKS Headers. I came across this older post that is a script you can run that will back up these headers; however, given the post is from 2021, is it still applicable/functional to unRAID today, and/or, can I just run a backup via terminal commands. Given it isn't something I need to run on any sort of schedule (my understanding is only when I add a new drive, or change my passphrase); doing it once via terminal is okay with me. Thank you in advance, and I'm excited to be joining the unRAID community! :)