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 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). Manually starting your containers one by one would circumvent this error as all containers are not attempting a 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 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.

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? Also question for you, and others here willing to help me out, I am running this on a custom docker network and running tailscale hook in the Immich container, but cannot access via tailnet URL. I read your networking sub sections, but I have done this before with Mealie and PostgreSQL database as well (also on a custom docker network); works great. The main difference is in Mealie, the docker accepts an BASE_URL variable where I typed by tailnet address to the service. Is there such a thing for Immich? Thank you in advance!

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. 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 lastest 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. 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 it just runs LUKS encryption and uses existing passphrase in backend) To add a keyfile to one of the remaining keyslots on the header (0 being used by my passphrase), I can use AddKey, BUT when I do this do I simply point it to 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!