Leaderboard

We are extremely close to releasing HexOS Local, our solution for accessing/managing your HexOS servers through a locally installed application on your server. Before we roll this out to all current users, we are looking for a handful that are able/willing to help us test the migration process. The requirements are pretty simple: 1) Users that agree to enroll in this early access test will have ALL of their servers migrated (we cannot apply the test to just a single server, so if you have multiple, it's all or nothing). 2) Users must have a discord account as those accepted will be invited to our new discord server for the purposes of bug reporting and support needs. If you are interested in helping us test this, please drop a DM to @mill3000 with the subject "HexOS Local Early Access" and be sure to include your Discord username in the message. Any questions, post them here! Thanks everyone!!

I'm out of town right now but let me just state that I totally get the folks that are upset. Honestly, writing blogs is pretty stressful for me as we constantly are working on moving targets and I stress over communicating about things that are still in flux and getting the words right. Tbh, I stress over comms in general. It's nerve wrecking. It's why I am earmarking funds this year to bring someone in to handle this for us. I just didn't want to spend any money on non dev/support resources until we got to 1.0. Again, I get it and I am not gonna make any excuses for it, so if you want to be mad, please direct that anger at me, not my team. They are busting their butts to get this thing polished and rolled out.

Another month, huh? The least you could do is respect the people waiting with some communication ahead of time. Instead it's silence all day on release day and a last-minute delay notice as if it wasn't clear days ago this could happen. You created this self-imposed deadline,, nobody forced it. A delay with advance communication - fine. But the silence until 9 PM? That's just pure disrespect

I don't know if "many" are thinking that, @vogam7, but I'm not. As @G-M0N3Y-2503 says this is par for the course in software development. "Communication" is a lot more work and headache than you would think and their time is much better spent on making the software.

We have no editorial input or control over the LTT videos. We don't pay for sponsorship or anything like that either. The fact that it came out this weekend was pure happenschance. We are looking into the SMB issue and will see what we can do from our side to address. Tbh, what we have planned for the rest of the year is going to have an even bigger impact than the 1.0 release in my mind. With respect to price, an announcement about our scheduling pricing changes will be coming soon.

So just to be clear... The initial deadline (end of 2025) got delayed. The self imposed new deadline (Q1 2026) got delayed. The blog post about the delay got delayed (and still not out). The extent of the communication in the meantime on they delay is a random comment buried in a random forum thread. Radio silence on the official comms (reddit, twitter, newsletter). Hard to see how that could be considered acceptable / consistent / reliable. What's the level of goodwill here to assure that even end of April release will be met? The track record so far now is the opposite - the self imposed deadline means nothing.

https://docs.hexos.com/blog/2026-04-02.html

Likely unpopular opinion, but thank you!

This one is entirely on me. I am traveling today but I will be working on getting this blog post up tomorrow (April 2nd). I'm also planning to hire someone to take over marketing/comms this year as a full time position.

It also could be the case that they've done a bunch of internal testing and are just gradually rolling it out. But In software development delays occur, and people will be upset. It's way better to phrase an initial role out as early access testing in case there is an unforeseen showstopper. Than say it's good and then be called out for buggy software. So really it's a matter of if they hire PR or a community manager or not. I vote that there are better ways to spend that money. Considering that roadmaps and timelines are just a guess to attempt to make people happy, from my perspective they've been about as inaccurate as I'd expect, so no red flags from my perspective.

Should be no risk to data loss at all. The biggest risk is getting disconnected from our deck for server administration. That's why we want users to be able to talk to us via discord so that we can quickly remediate those types of problems if they occur. The big switch here initially is going to be authentication. We're moving to key cloak and we set up a more robust infrastructure to enable us to migrate users between production and development environments very easily. While we've done a ton of internal testing on this, we just want to be extra cautious before doing a mass migration of thousands of users all at once. Technically this is still pre 1.0, but the only things that really remain for us are hexos local and some improvements to our health monitoring systems.

The teams working as hard as they possibly could on this and when participating in a beta delays, bugs and broken updates are to be expected. Personally I would prefer delays over broken updates.

1.0 should be out today. When will it be pushed out?

Hey, Seeing that you want to host a lot of VMs, may I suggest that you use Proxmox as the OS and Hexos as a VM. Proxmox is brilliant to run VMs while Hexos doesn't support VMs yet, you have to use the truenas gui and don't have the same flexibility as proxmox offers. Therefor, use proxmox ass your OS an Hexos in a VM. Just make sure to pass through the SATA controller to Hexos to give it HW level access and don't connect anything other then the Hexos drives to that controller. You can still just use Hexos as the OS and run your VMs in there, the initial Hexos setup is easier but you are not as flexible in the long run. There is no right or wrong in this one, both have there pros and cons. 🙂 HDDs: yes, avoid SMR drives as they are causing issues with ZFS. Go for CMR drives, but IIRC most, if not all 8TB drives are CMR anyway. Basically stay away from desktop and WD Red (non plus/pro) drives and go for NAS/Server drives. Check alternate if they still have refurbished server drives, might be a good starting point. And yes at least 3 drives now, to create a RaidZ1 which is expandable in the future. CPU: yes only AMD/Intel is supported. Intel iGPU from 12th gen onwards is brilliant for HW transcoding. 13th and 14th gen had problems where they died prematurely, but Intel supposedly fixed this with BIOS updates, but still a lot of people don't trust them, that's why some people don't recommend them. But you can still use them if you like, just make sure to use the latest bios and don't buy the F version as you mentioned. MoBo: whatever fits in the case and doesn't use a Realtek NIC. Typically ITX boards only have 1 pcie slot, so you can either use a GPU (for ML & LLM) or an Intel NIC or a HBA card. If you can go full ATX you don't have this problem anymore. Also most boards are either DDR4 or DDR5, you have to make your choice now. Almost no consumer CPU/MoBo supports ECC, so you will likely not be able to use your DDR4 EEC memory. Raid Controller: if you have enough SATA ports you don't necessarily need one. Network: wifi is a BIG no no! Neither Hexos nor Proxmox support WiFi you absolutely have to use a wired network connection, that's not optional but a hard requirement. Additionally Hexos doesn't not allow you to use your boot drive for anything else, so go with a small SSD (32GB are enough) if you use Hexos as your OS. If you use Proxmox, you don't have that limitation, there you can even install VMs on your boot drive.

Hey, you can't leave a cliffhanger like! Don't friends normally share bigger impacts with one another? 😁

We've added everyone from our list. We'll start to migrate people based on the order of purchase to local UI.

Just my 2 cents, but for me buddy backup is more important, since I have 2 Hexos servers and I can be my very own buddy and I'm not planning on every using a cloud service as storage (smartphone stuff doesn't count, you don't really have much of a choice there 😉 ) Additional Buddy Backup was one of the promoted features and there have been quite a few people asking about it since the initial release of the beta. Cloud backup on the other hand was not really promoted and as @Todd Miller mentioned there were far less requests for it so far. Therefore likely why they prioritised Buddy Backup over cloud storage. So from a commercial point of view Buddy Backup is a stronger selling point that sets Hexos appart from other NAS solutions. I'm not saying that cloud storage support should not be done, but at least this (forum) part of the community is currently more interested in buddy backup.

I did say BY end of April ;-). Truth is we have been pretty much right there aside from a few issues, but the big one was the availability of HexOS Local. But we decided yesterday that we can still call this 1.0 and roll out Local to everyone over time. The local project has to be rolled out more slowly as we have SSL cert issuance limits right now.

The nuance I see is: Guesstimate for initial release, end of 2025. Oh shit, people want a local UI? Guess that's fair but that's a tone of extra work... but here's hoping... (I like many assumed the local UI was a part of the original plan) End of 2025: So it turns out the local UI was a tone of extra work, but we have a better guesstimate, Q1 2026. 1 Week before the end of Q1: Ok beta-beta release, If this goes flawlessly we might just make it... End of Q1: So transitioning X all at once is a massive migration that you can't really test for that well, so we'll have to do it gradually so we can cater for the inevitable fallout. Maybe we can do that over a month? Obviously I'm completely guessing (see, lack of communication) and could be completely wrong, but the general rule I've seen is go off the magnitude of the guesstimate, the longer the period the less accurate it is.

Working on a blog post with an update. We had to push back to April due to some issues with our health system that we've been tracking down since February. The plan is to both begin the rollout of HexOS Local and complete the health system upgrades and then release 1.0 by end of April. I was hoping to get a blog up today with all of this information, but it just didn't come together fast enough.

I messaged the user. Thanks for the shoutout!

@jonp @mill3000

Wow, Communication is a headache? That's a laugh. Well it looks like you have come to the right place. You only get very filtered communication when things are going really good here. And for anyone who actually was a developer you already know communication is critical. A lack of communication leaves you with a forum like this. Dozens of questions that get ignored. When did communication and coding become mutually exclusive? Right now the only people talking positive about HexOS are a few folks that depend on this product for their livelihood. Fortunately most people seem to not care or never took anything said up to this that serious. And looking at how many issues there still are unanswered in the forums and the length some of those have been around. Some issues have been able to celebrate birthdays. And if you want something to think about, riddle me this. If communication is like this now when we are in "BETA" and there is still goodwill stemming all the way back to the LTT video, What will it be like when we have HexOS 1.* and the product is release to production. Do you think the communication will get better then? The entire team has made it easy to get down on this product/project but if your going to be honest with yourself you still see the possibilities that attracted you in the first place. If you love the product and you are honest with yourself you see the cracks and holes that give you an uneasy feeling. Everyone in the middle is pretty meh in that it will do what they need but maybe not what they want. And just off on the horizon is the real issue we have been dancing around. A perfect HexOS is still just a skin wrapped around parts of TrueNAS. It will never be more than that and no matter how hard you look you were never promised more than that. If you don't want to learn TrueNAS then welcome to a sturdy and easy to setup network attached storage appliance. As Immich has shown us multiple times, the application curation process was just to make the initial install easier and more standardized. It is not to make Immich work or eliminate code product issues and design changes. What kind of communication do you expect when a new release of an app or perhaps TrueNAS itself wants to change something fundamental like their storage or security models. And from who? It's probably time we stop worrying about when production version 1.0 is coming and start trying to figure out what we are willing to do to make it work. Learn TrueNAS? Buy new hardware? Buy consulting services? Cut your losses and find something else? Regardless of all the rest , it seems you can't count on communication or timelines here. If you can't live with that no matter what you thought in your mind this journey would be, well sorry because this is just the start.

@Ammonia some people seem to be getting that to work in this thread

First, a huge thank you to @lnkd for posting the actual steps to do this. All I did was follow everything they said and take pictures, so really all credit goes to them. Original post here: Prepare TrueNAS for reinstall: 1. Login to TrueNAS web interface – go to deck.hexos.com and click Settings: Then click the TrueNAS icon: 2. Once logged into TrueNAS, go to System > General Settings > Manage Configuration > Download File: 3. Read the note presented when you click Download File: 4. Click Save: 5. If you have encrypted datasets, go to Datasets > select the encrypted dataset > Export Key: 6. Now it is time to shutdown the server. In the top right of the TrueNAS web UI click the power icon and click shutdown: 7. Make your changes to the hardware that you would like – for me I added a 10 GB network card to run off fiber. 8. Prepare the HexOS installation drive by following these steps: https://hub.hexos.com/topic/103-illustrated-installation-guide-start-here/ 9. In your router settings, give the new hardware the same IP as your old one, then restart TrueNAS to grab the correct IP. 10. Once rebooted you can confirm on the server the IP address is correct: 11. Login to the TrueNAS web interface with the username and password you set during install (username should be truenas_admin). 12. Confirm your version on the dashboard – if needed, apply the update to the server: a. To confirm what version you need check the filename of the .tar file you downloaded from your configuration. It will have the version number on the end of it. b. Select the same version from the upgrade screen and confirm you want to switch to that upgrade train. c. Apply the pending updates and the system will reboot. 13. Go to Storage > Import Pool > find your zpool: 14. I have two pools so I will import them both. 15. Go into System > General Settings > Manage Configuration > Upload file: 16. The server will reboot after the configuration is applied. Log back into the TrueNAS server once the reboot is finalized. 17. If, like me, you replaced the network cards you will need to login directly to the server and adjust the IP settings: 18. Setup your new interface with the primary IP in CIDR notation, then you can log back into the TrueNAS server. 19. To setup apps, you need to go to Apps > Configuration > Unset Pool: 20. Restart your TrueNAS server then go back into Apps > Configuration > Choose Pool: 21. Once the pool is set you will see your apps again and be able to start them. 22. Navigate to the HexOS Interface (http://deck.hexos.com), unclaim your old server and claim your new one: 23. I ran into an issue where no matter what password I input it would not take it: 24. Currently troubleshooting that to be able to claim my HexOS server in the deck. All of my apps and storage are up and running so I will report back here when I fix this issue.

Sorry if this has been mentioned already. There needs to be a way to store a boot disk config or recovery file on one of the arrays to allow easy recover of a dead boot drive (all done within HexOS! I shouldn't have to go into truenas if I don't know what I'm doing). I did install on redundant boot drives but bought too cheap and they both failed simultaneously. The only way I could find to recover was a fresh install without the array drives connected, then plug them in and manually recreate the exact share folder names in the HexOS from the list in truenas. Also, I would love to see a way to transfer or transition the boot drive to another drive by simply connecting a new drive. That way if all you had for a boot drive was a 1 Tb but wanted to use that for something else later you could get a smaller drive and transition.

Shame on you all. Sam Jackson would not approve.

Love this guys content!

As the title said, I have been holding out since I purchased the key. Recently heard on the LTT podcast that 1.0 was launching at the end of March. Is that still the plan? I haven't seen an official blog update in a few months.

All we can say at this point is we are slowing rolling out local to new users. Over 400 so far have been migrated.

I bought my license the day it became available but I've been waiting on this release to install. My server has just been sitting in the rack waiting. Excited to finally try it out, hopefully the download becomes available soon.

I have just recently added a To GPU to the NAS to help with Plex, would be nice to have statistics for it on the main dashboard page. Also might be nice to have a settings page that allowed you to select to use it.

Don't get me wrong, the communication is at what i would call a minimum, any less and I'd guess it was abandoned. But, it's a consistent and reliable minimum so far. I check the forum every other day, so would i appreciate more details, definitely. But would i trade anything for that outcome, probably not. So with the minimum communication and knowledge of the software development process patterns, I'm content enough. But that's not an expectation for others I have either. If you'd trade a license for that outcome and the team decide that they should improve communication because of it, hey, that's good too,

The people saying everything is fine have got to be software developers who see this only from one perspective. Hate to break it to them, most people we'd expect soon to pay full license fee to keep the project going aren't, and those are exactly the potential customers we'd lose with this laid back mindset to weak areas of this project. Those won't be beta expectations anymore and there will be a lot to prove to doubters of this project to justify the price. Imho plex & immich was genuinely exciting to watch grow naturally, and backing them early felt like a bargain especially towards stable launch. Was it perfect? No, there were delays too. But none I recall having such communication meltdowns close to stable release. I'll be honest, some of the responses here concern me as much as the delays and comm issues themselves. Some say I knew it's part of the process "when I read Q1 2026 I think Q3 2026" maybe, but not this far into this beta with no updated written delay comms. Others react confused when I try to hold the team to their own deadlines. 'I'm glad they're not communicating, that means time is much better spent on making the software...' really? Good teams do both and I'm not asking for daily extensive blog posts of what and why went wrong, just a sentence update across all hexos communication channels setting new expectations. I recall people on this very forum calling out poor communication back in July and October, and the team acknowledging it and promising to improve. Yet here we are. Traveling or not, I still don't understand how the whole team forgot the most anticipated day of their own project, or couldn't break the news of a delay at least the night before. Now whether April Fools or not, yesterday would've been the first day after stable launch with customers paying $300 for a license, needless to say the most expensive nas os on the market. At this point, if the team still offers a refund option, I'd happily take it.. this just isn't for me anymore

Well @vogam7did you get what you wanted? If you have read these forums there are more than enough accusations of terrible or completely lacking communication. I have been jousting with this windmill since shortly after the initial deployment. I've even talked about to many methods of communication that left each incomplete. I got a similar response it would be looked into. and I can say this was the only answer you could have expected. They are probably still a small team primarily of coders. There had been talk months ago of no marketing team, no support team, and only initial talks of ongoing funding. If we are thinking this communication level is the biggest issue we are going to face before this project stabilizes, we are seriously kidding ourselves. That LTT video is more of a curse than blessing because this project isn't ready for that kind of attention. This team isn't going to acknowledge they are having trouble. They just won't say anything, again. And there is nothing any of the paying beta customers can do about it. Watch and wait or don't watch, what's the difference now. It's to late to change the approach the team took, even if they have found that. And there is now reason to assume that's true. Did they take the right path to this development? Did they build the right team with the right leadership? Well, if you have a better plan then share it. If you don't like this approach how would you fix it? Communication alone means very little. Missing deadlines is a much bigger deal that not mentioning there are problems. And honestly, do you think this would be simple and smooth? Yeah right.

According to this picture found at https://nascompares.com/2024/10/04/jonsbo-n5-review/ , it seems like he has added the 4 SATA cables and 1 SATA Power cable to the board, no MOLEX. My best bet is that you can either use MOLEX or SATA Power, but don't need both.

"Working on a blog post with an update. We had to push back to April due to some issues with our health system that we've been tracking down since February. The plan is to both begin the rollout of HexOS Local and complete the health system upgrades and then release 1.0 by end of April. I was hoping to get a blog up today with all of this information, but it just didn't come together fast enough." -JonP "I am traveling today but I will be working on getting this blog post up tomorrow (April 2nd). I'm also planning to hire someone to take over marketing/comms this year as a full time position." -Jonp Link to discussion

It works

I'll just say what many are thinking here.. you're launching a hexos local beta just 9 days before the promised stable release date. How could this be included in 1.0 and called stable in under a week of testing? Refunds seem to be the go-to response for anyone who expresses frustration in other threads.. but that's beside the point for those of us who actually want this project to succeed. Missed deadlines are frustrating enough, but the communication issues that still keep coming up alongside them make it worse.. and for a project that depends on people investing in hardware, that trust matters. Server memory and now drives have nearly doubled since the originally promised end of 2025 release date. Every delay has a cost beyond just frustration. A straight timeline update would go a long way. I don't think you meant it this way, but the timing of this post is pretty telling... are we in for another delay?

It has gone rather quiet. I thought I would see more general discussion or the odd update. Unless I've missed something the most recent update has been a revision to the blog introducing hex OS local originally published 25th Nov 2025 and updated 23rd Jan earlier this year. I'm not complaining before anyone jumps on me. I've been happily running the beta since originally hearing about it on LTT and couldn't have built my NAS without it (not with my skillset at the time anyway). So far it's been running flawlessly, shares and apps have been a breeze to set up, and the minor jobs I've had to do myself such as setting up a VM in truenas for Homeassistant have been recognised and appear on the Hex OS dashboard. I know it's possible I might have to start again from scratch but fingers crossed there is an update path that doesn't break everything. I have on occasion had to re-adopt the server on the dashboard (probably my fault) but it's only happened a couple of times. To avoid wiping everything I just popped out my drives, re-adopted, shut down, popped the drives back in and everything came back when I restarted. If there isn't a simple update to 1.0 with any luck a similar workaround will prevent data loss.

At this point, just using HexOS to create folders, users, install apps, etc. just like normal. Use it both locally and remotely. That's really it. At this point, the main thing we're testing is that it works correctly, navigating you to the local interface when on LAN, and giving you remote access via the deck when away. If you can break your system (non-critical data only), there are a few specific cases we would like to see users test like destroying the pool used by apps (Docker) manually via TrueNAS, then renavigate to deck.hexos.com to see if you can remediate the issue. Obviously not asking anyone with real data on their systems to do this, but for those that have test setups, just beat the heck out it and see what breaks. We test internally pretty rigorously, but there's always edge cases that we can miss and this is the chance to find those as best we can.

Hello all! We are excited to announce HexOS Local, powering the new local UI/UX for HexOS and capable of so much more. Read more about it on the Blogpost - Introducing HexOS Local

if im not mistaken it looks like it isn't a docker application. you'll likely be able to get it running inside of a linux vm

I'm having the exact same issue on 25.10.2.1 — so the update alone doesn't fix it. I dug into it and found the actual root cause: The ix-vendor.service runs /usr/bin/start_vendor_service on boot, which calls vendor_service.py. This script starts a transient systemd unit called websocat.service (the websocket bridge between your local middleware and deck.hexos.com). The problem is that the script doesn't check whether websocat is already running before calling systemd-run --unit=websocat. If websocat is already active, the call fails with "Unit websocat.service was already loaded", but the script always exits with code 0 (it has a finally: sys.exit(0) block). Something then re-triggers ix-vendor, it fails again, and you get a rapid restart loop. Each loop iteration spawns a Python process that opens Docker sockets, and since the middlewared service only has a soft file descriptor limit of 1024, the FDs get exhausted quickly — hence the "Too many open files" error. Here's the fix that worked for me in truenas shell — a systemd override that adds a simple check before running the script: sudo mkdir -p /etc/systemd/system/ix-vendor.service.d/ sudo tee /etc/systemd/system/ix-vendor.service.d/no-loop.conf << 'EOF' [Service] ExecStart= ExecStart=/bin/bash -c 'if systemctl is-active --quiet websocat.service; then echo "websocat already running, skipping"; exit 0; fi; /usr/bin/start_vendor_service' EOF sudo systemctl daemon-reload sudo systemctl restart ix-vendor.service After this, ix-vendor shows active (exited) with status 0, websocat keeps running, and deck.hexos.com works fine. No more loop, no more FD exhaustion. I also raised the middleware FD limit as an extra safety net: sudo mkdir -p /etc/systemd/system/middlewared.service.d/ sudo tee /etc/systemd/system/middlewared.service.d/fd-limit.conf << 'EOF' [Service] LimitNOFILE=65536 EOF sudo systemctl daemon-reload sudo systemctl restart middlewared Both overrides live in /etc/systemd/system/ which - as far as I understand it "so far" - survives reboots. After a HexOS update you may want to verify they're still in place. Hopefully the HexOS team can add the is-active check to vendor_service.py itself so this gets fixed upstream.

Try the following. Most likely this will fix your issue. If this does, TrueNAS has a fix that is in it's next update. Login to TrueNAS interface. Left side select "system". Then after screen refreshes select "shell" from the list. Paste in the following command. *Can't use normal short cuts* Will need to use Shift + Insert Key for pasting. sudo python /usr/lib/python3/dist-packages/middlewared/scripts/vendor_service.py If that works within about 1 min you should be able to go to deck.hexos.com and see your server or claim it. You might need to run this after reboots. Let us know if this works. Thank you,

Genius! Thank you so much for this, genuinely. Whatever this bug is has been preventing me from upgrading for months. I'd check updates once in a while and then just regress and go back to running 25.04. As soon as I hit ENTER key on the last line of the script, everything settled down immediately. I think you can tell at what time the script was entered lol.

Let's Talk About Immich If you've been running Immich on HexOS this year, you know it hasn't been smooth sailing exactly. We want to talk about what's happened, why it was so challenging, and how we're working to handle these situations better in the future. What Happened? Earlier this year, Immich deprecated their old storage configuration and required all users to migrate to a new structure. For users running Immich through docker-compose or other manual setups, this meant updating some configuration files and running a few commands. Annoying, but manageable. For some HexOS users, the migration was more involved. Because of how TrueNAS SCALE structures application storage, moving to the new configuration required either reinstalling Immich fresh (the simplest solution) or manually migrating existing data between datasets (a process that involved SSH access, rsync commands, and careful attention to permissions). But if you're choosing between "reinstall the app" or "follow a 15-step guide," neither option feels great when you chose HexOS specifically to avoid that kind of complexity. Why Was This So Hard? When Immich made this change, we had a choice to make. We could have built a comprehensive rsync-based migration tool using the TrueNAS API. It has those capabilities. But that would have meant dropping everything else we were working on to build what amounts to using a cannon to kill a mosquito: a massive, complex solution for what we hope won't be a regularly recurring problem with this particular app. Instead, our community stepped up in a huge way. Users like @forsaken and @G-M0N3Y-2503 created detailed guides (to move or rsync your data). These guides walked through the manual migration process to preserve existing data in Immich. They focused on helping users through the immediate problem, while we continue building the platform we need to handle situations like this properly. That platform is HexOS Local: a locally-hosted management application that will let us perform complex operations without being bottlenecked by the engineering overhead of building one-off solutions through the SCALE API every time an application throws us a curveball. This reduces the technical burden on our team and, more importantly, gives us the flexibility to automate maintenance tasks that previously would have required manual intervention or massive engineering investments. This same platform will serve the Local UI/UX feature we've committed to delivering as part of our 1.0 release. We'll be talking a lot more about HexOS Local in an upcoming blog post, but the key takeaway is this: we're building HexOS to handle whatever the open-source ecosystem throws at it, without having to choose between "drop everything and build a custom tool" or "make users SSH into their servers." What About Right Now? If you're currently running Immich on the old storage configuration and haven't migrated yet, you have options: The simple path: Reinstall Immich fresh with the new configuration. Your photos will need to be re-uploaded, but the setup is clean and straightforward. The preservation path: Follow one of the community migration guides to keep your existing data in place. These guides are more technical and require command-line access, but they work. Our recommendation depends on your situation. If you have a manageable photo library and good backups, the fresh install is probably your best bet. If you have years of photos, carefully organized albums, and user configurations you don't want to recreate, the migration guides are there for you. And if this seems to daunting, email support@hexos.com so we can schedule a time to assist you directly. Moving Forward The Immich situation showed us exactly where we need to invest engineering effort. We can't keep facing the choice between building massive one-off solutions or asking users to break out the terminal. That's not sustainable, and it's not the HexOS we're building. Immich is an incredible project. It's exactly the kind of self-hosted solution we want to make accessible to everyone. The team behind it recently released v2.0, marking their stable release with better upgrade paths going forward. We're committed to making sure that when the next complex maintenance task comes up, whether it's Immich or any other application, we have the infrastructure in place to handle it gracefully. That's the HexOS we're building. Thanks for your patience while we get there.

I forgot to answer about the Hexos license transfer part: Yes, that is possible and even very easier. On the Hexos website you just need to unclaim your old server and can then reclaim your new server, but It might take a couple of hours until your license because available again after unclaiming it from the old server.

Hello, One way that could fix this is to do the following. Update to TrueNAS version 25.10.2.1. which applies permanent resource limit fixes. Thank you

@Dylan OMG OMG OMG I figured it out! I went into TrueNAS and found the Applications dataset, found the permissions and everything looked fine there, but I also noticed that under the Applications folder there was the Plex folder. Only the Plex folder. Because I had only installed Plex, nothing else. And since I uninstalled it, it shouldn't still be there. The fact it is still there, I reasoned, could be causing issues when it tries to install. I figured it must not have fully deleted the folder during the uninstall. So I deleted that folder and then tried to install Plex again through HexOS and IT WORKED! So happy! Thank you for pointing me in the right place!