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!!

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.

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.

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.

If you're seeing 'Failed to start transient service unit: Unit websocat.service was already loaded or has a fragment file', then you can try: sudo systemctl restart websocat

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,

I... I was... I would have.... FUUUUUUUU-- Ordinarily, I would absolutely have tried another USB, and I actually was trying a bit ago, but that drive was being funky and wouldn't connect to Windows well and I gave up. I completely overlooked trying Balena Etcher (Rufus has always been rock solid for me so I never bother thinking aoub it) but NOW THAT YOU'VE SAID IT I feel like I remember needing to use it for CORE back in the day TOO! I am an IDIOT! Anyway, I grabbed a third USB, Etcher, and a new copy of the .iso, and set it all up again, and wouldn't you know it, the damn thing worked. Installed HexOS to the SSD, plugged in the HDDs and went to boot, and the box picked up the data drives to boot to. I thought I wasn't out of the weeds yet, but on a whim I tried re-enabling the B120i and going in and deleting the RAID array on the drives but keeping the single "array" on the SSD, which allows me to set the logical array as bootable in the B120i. Rebooted and... LOOK! HexOS!! I am as much at fault as any part of the technology in this thread, but in the end, through all that crap, and with your help, we got there, so... THANK YOU very much!!

Hey, please keep us posted about the progress. Concerning why you shouldn't use a HW Raid in combination with Truenas, the official ZFS documentation has a great section about this you find it here: https://openzfs.github.io/openzfs-docs/Performance and Tuning/Hardware.html#hardware-raid-controllers

Hey, The quickest check which you can do; when you connect a display to your server, what IP address is shown? 10.0.0.28 or a different one?

Hello, It seems the after the update some systems on reboot are reaching out to our server so it doesn't know your there. Try the following. 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.

For this, the fix was to in HexOS go into Settings > Reset > Unclaim System. Then reclaim the server and it should be fine. From what I can tell it gets like that because when you reclaim the server before restoring the config backup in TrueNAS the API key is different than what HexOS has so when you reclaim the server it checks and see the API key in TrueNAS and uses that. Sidenote if you are importing your config file back into TrueNAS for the apps if they are gone and nothing happens after you set the pool, try unsetting (unset pool) then select the pool again it and then it takes a bit to run through the HDDs and bam it comes back.

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.

Offline Server for when SHTF happens. Anyone seen this yet? It’s from the guys over at crosstalk solutions. Wondering if it can be loaded as an app or a VM???

I would like to see first party support for placing any app behind some of the most popular VPNs (PIA, Nord, Express, Proton, Tailscale, etc), as well as custom VPNs (WireGuard, OpenVPN, etc). For example, you may install “The Lounge” IRC client and have all internet communication pass through a PIA VPN so that your home IP is not exposed while chatting. Traditional methods of doing this involve painful configuration of iptables or other firewall rules. I believe this is an area where HexOS could really simplify things: Install a VPN plugin, authenticate with it, and then simply assign an app to a VPN plugin via the app’s settings if desired. It would be fully accessible from the home network without going through the VPN, but all internet traffic would go through the VPN with a kill switch in case the VPN goes down. Thoughts?

i have this issue as well..march 2026 and still not fixed...i give up

Ignore me, I just found the 'expand' button 🤦‍♂️

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.

So, I built twin HexOS systems (almost) in Jonsbo N5's 1 Ryzen 9 9900X (12C/24T) and 1 Ryzen 7 9700X (8C/16T) 1 RTX 4070 TI and 1 RTX 3070 For both: MSI Mag X870E Tomahawk 96GB DDR5 Boot - Crucial P310 1TB in Raid 1. Storage - 4 x Seagate Ironwolf Pro 4TB RaidZ1 1000w Modular PSU PCIE X8 SAS card and onboard to connect all 12 bays in the N5 Intel X550T2 Dual 10GbE NIC Full case fan replacement with Nocuta fans and a NH D15 cooler. Mirrored backups between the system over Tailscale and one machine moved from my house to the workshop 30mins away for offsite actual a backup backup. Too much? ETA- I built them in August last year, before things got...too crazy

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

I can confirm that if you do a fresh install you can set up the folders again and have access to all data, but you need to do things in a specific order and with the array disks unplugged (if you try to set up a new array through HexOS interface it will wipe the drives). If you know all your folders now you won't need to go into into truenas. I really think there needs to be a recovery feature in case of boot drive failure. Here's a link to a thread with good instructions on how to recover, but it would work to "downgrade" as well, though kinda janky. I would assume cloning would work as well but haven't tried it. https://hub.hexos.com/topic/3227-restoring-hexos-from-a-dead-boot-drive/

With all the other apps curated so far it would be awesome to see nginx curated for DNS and HTTPS resolving. It already exists in truenas scale as Nginx Proxy Manager. This would allow hex os users to access their apps externally without VPN hosting, to resolve DNS requests and utilize https.

The reason Tailscale gets recommended so often is because it (and VPNs in general) is the most secure ways to access your services remotely. It's also pretty easy to install and get running. Nginx, on the other hand, is a completely different approach. To make lives a bit easier, let's take Nginx Proxy Manager instead of plain Nginx. Installing it is the easy part. The real work starts afterwards. You’ll usually need a domain, set up a DNS token for the certificate DNS challenge, configure something to keep your public IP updated, and create and manage all your subdomains. And all of that just to make your services reachable from outside your network. Once you’ve done that, your services are basically exposed to the entire internet. That means any device online can try to reach them. Because of that, you also need to put additional security measures in place to protect them from people trying to access or exploit them. Therefore only expose what you absolutely need to expose.

You rock, interesting fact, Chat GPT highlighted this post. Giving you Credit because i was also trying to fix this.

I had the same issue where HEX Deck would not recognize my server (deck said it was offline) but TrueNas UI worked. I realized it was my fault, I blocked it on my ubiquiti firewall accidentally when i was troubleshooting another issue. That's why truenas works because the HEX OS Deck has to call to Eshtek's server and the truenas ui does not. to answer another question in this forum, the local ui will mask this issue, not fix, because it will allow local connection, but wont change the fact that your server is blocked from external internet firewall level so connected to Eshtek wont work (only for this exact issue though). Another symptom of this exact issue was truenas did not have external internet access either, the app catalog was failing to update. Good luck to you guys hopefully this helps.

Hi I wrote the next blog https://www.gingerling.co.uk/how-easy-is-hexos-to-resurrect-when-youve-ignored-it-for-3-months-because-you-had-a-new-boyfriend/

I have always purchased new exos drives from ebay. My last batch came straight from seagate themselves.

Nor do I! As I said I've always had a great time with Rufus so I didn't even think about it - that said, Rufus DOES, of late, pop up a note about the ISO image type, and not having all the files it needs when preparing to write the HexOS ISO - see below: This reads to me as "click yes and everything will proceed according to plan" but, there could easily be something going wrong during the 'attempt to download' the required GRUB file(s). I should really have thought more about these when I saw them but, because HexOS load(ed) at least initially, and because the image seems to show up fine, I assumed it wasn't a problem, and made the proverbial ass of myself. Thanks again for all your help here, sincerely! I still might reserve the right to be mean to my NAS for a while just to let out my frustrations 😆

Happy to see that it's working now for you. 🙂 I still don't understand why this makes a difference which software you are using to create the USB drive, but hey at least it's running now. =D

In that case, did you try another USB drive or just 1 single drive? Also try using Etcher instead of Rufus.

The above messages are coming after selecting the boot drive where Hexos should be installed or beforehand?

Hey, You changed the Truenas GUI ports, that's the problem. The Hexos button is pointing to the port 443 (https) or 80 (http) but nothing on the server is listening at that port thus the rejection. You currently cannot change the destination ports of the truenas gui button in Hexos. To keep its functionality, you need to revert back to the ports 80/443. If you want to keep your custom ports, bookmark the page in your browser 🙂

Hey it would be cool to have a straight forward way to install Nextcloud (e.g. the all in one edition https://nextcloud.com/blog/how-to-install-the-nextcloud-all-in-one-on-linux/) on HexOS. I set it up myself on my homelab, but the setup was not as easy and while the software itself works great, I'm not as satisfied with my implementation. It offers a lot of features with a client that is available on a lot of devices already, essentially substituting Cloud storage, Google Calender, Contacts, Office products, Slack (e.g. for small businesses) and as I just saw even LLM like ChatGPT. This would add huge additional value to HexOS, since you easily could substitute a lot of subscriptions that way, while having enormous privacy benefits, a thing the target audience of HexOS would surely profit of. Especially if there is also a way to safely expose it to the internet.

Next cloud has already been curated by HexOS

this is correct however there is one more limitation, only pools that consist of 3 or more storage drives can be expanded. 2 drive pools have no option for expansion 3+ drive pools can be expanded with drives of the same or larger capacity of the smallest drive in the pool yes if you have a pool that has 4 drives you can add another later to increase the pool size, giving you more space

Forgot to update when I did this, but replaced my 8TB drives w/ 24GB ones when they were on sale. Glad I went for it since those drives are MUCH more expensive now.

This fixed my issue I was having with HA, thank you! 🙏

First, let me start by saying I actually really appreciate this question and I hope my answer gives you faith in our long-term sustainability, exactly as you mention in the title of this thread. The lifetime license model is appropriate for a very particular type of customer with very specific priorities: Bring your own hardware Doesn't want an ongoing subscription Will mostly support themselves It was the appropriate model to launch with as well because it allowed us to inject a larger cash infusion at the start. However, we see multiple additional revenue streams available to us in the future: Subscription-based licensing. A lower price of entry for customers that aren't ready to make the lifetime commitment. Support. A more premium support model that can help you on a 1:1 basis when you have issues with your server. Cloud-based Services. Things like cloud backups (as an alternative or in addition to buddy backup). There are other cloud-assisted services such as reverse-proxy/relay that may warrant a subscription as well. Hardware products We will never force anyone to buy a specific hardware product to use HexOS, but we may offer some for those that don't want to build their own in the future. We actually have a few other ideas for additional offerings as well that would add additional revenue streams to Eshtek, but those are a little premature to discuss at this point. Bottom line: we don't just have a product plan, we have a full business plan for the future of this company and it has been designed to ensure a few key things: We don't run out of cash. We don't have to take on outside investors. We can remain true to our mission and vision. I hope this answers your question and gives you more confidence in our plans for the future. And if you have any other questions, don't hesitate to ask!

We push updates out now in the UI/UX itself too every time we do one. Check your notifications.

Hey there, unsure if this is the correct channel to post a suggestion, please direct me elsewhere if not. I was just expanding an existing pool from inside the UI after adding a new drive to my NAS, and after doing that I (wrongly) assumed it would be almost instant to expand the ZFS pool, because it isn't something I have done before. When I did it, I was surprised to see it stay on 25% for a long time, because I didn't know any better, and assumed something had gone wrong/got stuck with HexOS being beta software, which wasn't helped when I checked the TrueNAS interface and the running jobs said it was created by [object Object] which really made it feel like an error had happened somewhere.... After a bit of research I realised how expanding pools actually worked, and could see in the CLI that it was actually working and there wasn't an issue at all. I suspect it being stuck at 25% is an upstream TrueNAS issue, but a warning message that this process will take a long time to copy the data to the new disk (and maybe warn it will be stuck at 25%) within the HexOS dashboard would probably be a good idea to ease the worries of less savvy people who would see that and assume something went wrong, and potentially cause themselves issues by rebooting or something like that. Thanks, loving the software so far and I hope my suggestion can make it just a little bit better, keep it up!

I’m currently trying to migrate from Synology to HexOS/TrueNAS, and I’ve run into a major adoption hurdle. While TrueNAS is clearly powerful, the migration experience is not approachable for users who don’t fully understand every feature and configuration detail. Despite trying multiple approaches—including rsync/rsyncd and several YouTube tutorials—I wasn’t able to complete a successful migration from my Synology system to HexOS/TrueNAS. The tooling assumes a level of familiarity that many prospective users simply don’t have, especially those coming from more turnkey platforms like Synology. What’s critically missing is a guided migration wizard: something that can automatically discover or map existing Synology file shares to target shares on HexOS/TrueNAS and handle the data transfer with sensible defaults. This would dramatically reduce irritation, shorten time-to-value, and prevent users from abandoning the platform during their very first experience. In my view, a first-class migration experience should be a top-priority feature. Making it easy to move data from popular platforms like Synology would directly lower the barrier to entry, increase confidence for new users, and significantly accelerate adoption of HexOS/TrueNAS.

Hey, No this has been fixed months ago, with the Q1 update I believe.

I’ve changed the default port numbers on my TrueNAS web server to free up ports 80 and 443 for other services. However, from the HexOS portal, it still tries to connect using the standard ports when interacting with TrueNAS. For example, if I try to edit an app’s configuration or launch the TrueNAS configuration from the portal, I don’t get the correct interface. It would be great if the portal could detect the configured port numbers via the API, or allow these to be set manually in the HexOS settings.

Saw your post and I’ll add this to the list for us to curate. Seems like a good one!!

I just recently started building my NAS and many of the containers I run I have seen in this form but I also have been using audiobookshelf to host my own library of audiobooks. I have to use it in conjunction with tailscale to access it out of my network so maybe it is not ideal for "simplicity", but I would love to see something like this come to HexOS in the future.

Currently doesn't look like there is one - I would definitely like a search as well. Maybe if they swap to Discourse?

We're thinking of supporting the install of something like Portainer. Would that satisfy your needs? If not, what platform would you prefer?

It seems like the TrueNAS Scale build repo on GitHub is "no longer actively maintained": https://github.com/truenas/scale-build Will this affect HexOS in the long term?