Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 05/08/26 in all areas

  1. Intel cards are well-supported by TrueNAS Scale. With that said I can't guarantee it but it should. Once you install it you'll have to update a few things if this isn't going to be a new install. On the server once fully booted you'll have to go through options 1 and 2 to make sure it knows to use the new network card. Once that is set you can log into the new ip address for the TrueNAS UI. Once in there you'll want to update the network settings to make sure the settings are correct for the new network card. Last step is edit the HexOS app in the app section of TrueNAS. You need to update the ip of what your TrueNAS was with the old network card to the ip of the new network card (Ip with TrueNAS WebUi). Just go down till you see a setting with the old ip and update to the new then scroll to the bottom to save it. Hope this helps. Thanks for supporting HexOS.
    1 point
  2. Thank you so much for this fix, it fixed it for me as well. I have been having the issue since the first Goldeye update, and this finally fixed it. I'm on 25.10.3 and still have the problem.
    1 point
  3. This happens to me at every update... Annoying! Thanks for the solution!
    1 point
  4. Since the rollout of HexOS local the "hexos (ix-app)" showed up in the TrueNAS app list. Makes sense for running HexOS local software on TrueNAS. The app is showing to have available updates in the TrueNAS app list. Of course, this app doesn't show up the HexOS Deck interface. So I cannot update it from there. My question is: - What should I do with this app? - Should I update it manually? - Will HexOS update it automatically? When? - Why does it show an update but didn't update automatically yet? I understand, that the intention for HexOS is to never have to touch TrueNAS. For my use cases I do very often and just wondered about this.
    1 point
  5. 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.
    1 point
  6. That worked thank you so much
    1 point
  7. 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.
    1 point
  8. +1 definitely passkey support
    1 point
  9. I suppose if there was a priority, that had to be set. I would rather have Passkey support over 2FA.
    1 point
  10. +1, and maybe passkey support?
    1 point
×
×
  • Create New...