mikescott

Hey sorry for very late reply. I thought this might be solution as well given I came across this post outlining something similar to get it working that I actually had to do for one of my other containers. Alas, I did the same thing as you, added a path variable and added the corresponding .tailscale_state appropriately...but still nothing. Maybe because I'm explicitly defining the UID and GID in the docker template as 99 and 100, respectively....I always do for my containers on unraid. At this point, my only other option is to spin up a tailscale docker container for joplin and route joplin through that. Unless I remove 99:100 and let it run as root...but not ideal no?

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/