Leaderboard

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.

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?

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.

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

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.

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.

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?