Leaderboard

Another mid-quarter update featuring: - Install Script v2 with interactive questions during app installation to support user preferences (eg. Plex claim code) - Fangtooth Support with full TrueNAS 25.04 compatibility and automatic pool upgrades - Enhanced User Management with better visibility and access to folder permissions Read the full release notes: https://docs.hexos.com/release-notes/command-deck/2025-11-06 NOTE: This update was applied automatically. You may need to clear your cache.

Just sharing some good news — my update went smoothly, and all apps, VMs, and backups are running normally under Fangtooth.

Unfortunately there are 2 version numbers for the apps in the truenas app catalog. The "version" which is what you see in hexos, this is just the iteration of the truenas docker app which has nothing to do with the overall application which is also called "app version" you can see both of these numbers in the truenas interface if you would like but here is a screen shot My "version" is 1.10.12 but that is the same thing as "app version" 2.2.3 so we are not actually behind. i totally get the confusion though and ill be sure to bring it up with the team. Just to clarify a few things Truecharts is a third party app store that afaik shut down and was never compatible with hexos All the apps you see come from the Truenas apps market which i believe is first party to truenas HexOS unfortunately does not have any control over app versions (as much as i wish we did for troubleshooting), this is all truenas

Yup it was added last night! Check the original post for instructions.

Thanks for reporting these issues. We are taking this feedback to heart and will work to address.

Hey, It seams to be possible to use a GPU with multiple apps, but you need to login into truenas to do this: https://www.truenas.com/community/threads/can-multiple-apps-utilize-the-same-gpu.99757/#post-712876

Hello! Are there plans for HexOS to allow users to use (mirrored) SSDs for ZFS' tiered storage optimizations? The main three uses I'm thinking of: Enable high-endurance mirrored SSDs to accept synchronous writes (SLOG) Enable mirrored SSDs to store all file metadata (special vdev) Enable mirrored SSDs to store all small files (special vdev) While I'm sure popping into TrueNAS (for those with that experience) would work, I think implementing these directly in HexOS would be quite beneficial even for consumers with many small files and / or macOS devices. While not all performance-based vdevs are helpful in most scenarios, these would be great, especially the special vdev for small files, e.g., use the ultra-fast random access of SSDs for video editing project files or documents (special vdev) and especially the SLOG vdev for macOS SMB writes (always sync writes). Of course, in some far and away future, HexOS would identify when these vdevs would significantly improve performance, but manually turning them on & testing them out would also be neat through HexOS. I'm intentionally ignoring L2ARC, which requires much more careful hardware selection & tuning to get any benefit.

I also had the same error and can confirm I am updated to 25.04 Fangtooth from TrueNAS: Might be a good idea to add a panel like this to the deck to confirm the version number, or if there is already one I cannot seem to find it.

Thanks for confirming. I managed to successfully upgrade last night using the rsync method. Although I had to research how to do the SSH part, perhaps you could add this instruction for others? Otherwise the method comes across as very intimidating when in fact it was relatively straightforward.

i believe there is a skip setup button now. i would skip setup and then go into truenas to adopt your existing pool

For the issue with immich right now, the guide is the best option. We are planning for a more elaborate way of addressing app issues like this that will put less burden on the user, but we have to build our own local app for that first.

hexos will not show the drives as used as support for special vdev in the hexos interface was never added. once a special vdev is added to a pool, their use is automatic. You don't have to worry about hexos seeing or not seeing it correctly.

Thank you for your reply, @Mobius. That does make sense. To your final note, hopefully by stable, if we manually create these vdevs in TrueNAS, they can play nicely with HexOS. — I agree: I believe folks recommend the special vdev to have the same redundancy as the data vdevs; if it were to be added, hopefully that recommendation could be prominent. I've heard mixed things about performance: for many-file directories, it can feel snappier, which is what I hope. SLOG: ah, I had another angle. My main interest are a couple of wired Macs on our network as Macs write to SMB synchronously (straight to HDDs), without fast RAM-first writes like Windows machines. But with an SLOG, Macs write to this faster SLOG vdev, allowing the transfer to complete faster. So with an SLOG, Macs have virtually identical write performance as Windows. But without the SLOG, Macs write a little slower. We definitely use a UPS; it's a solid investment for data integrity as you get PLP for the whole server! A great recommendation.

i'm not gonna go as far as saying never gonna happen but i'd say its on the furthest back burner if at all. special vdev is a scary one to implement because if it goes down, itll take the whole pool down with it on top of not being very useful for most homelab users slog also doesn't make the most sense for most users as to my best understanding it only really protects you in case of power loss and at that point you might be better served just getting a ups. Personally i do run a triple mirror special vdev on my storage pool and i think it causes some stability issues with hexos.

In case there is any confusion still on this topic, a local UI is coming...100%. We actually have already begun work (we have a docker container with the UI running at this point, but it's not fully functional yet).

@Dylan Thank you for your help! It really helped me get a better understanding of the bigger picture in regards to all this, and it helped me kinda jerryrig my own solution to it. Thing is, shortly after installing the OS I had also decided to update truenas scale, which I found out later that it isn't recommended to do so. It didn't break anything for me at least, so I just figured it's all good. But after having wrestled with the guides you sent me, and stumbling upon a random reddit thread, I ended up finding out that the issue causing this whole mess was that I had basically done a "default installation" of pretty much everything in Handbrake when doing it via truenas scale. So part of what the latest version of electric eel (truenas) did, was change how the apps are handled - and how they are placed, which is more relevant for this - which messed with how handbrake sets up storage paths to "watch" and output from how it's installed. The people in the reddit thread were talking about how it's essentially a "1-click solution" to change the already-existing apps to fit that update, but they didn't really talk much about when installing from scratch. Which is where that guide by Theo about radarr and sonarr really helped out, because it made me familiar with the finnicky nature of the storage options and premade datasets when installing something. So this is what solved it: (I had already deleted handbrake quite a while ago, so at this point it's without the app installed) I made a dataset for handbrake, in /mnt/HDDs/Applications/ with permissions set to user, group, and other, with root and read/write/execute (I figured why not, I didn't really feel like taking it one permission at a time and I'm fine with leaving it as it is now, but up to you (the reader) if you want to be more cautious about it). I did not make a config sub-dataset like the sonarr/radarr guide suggests for sonarr/radarr. I then installed handbrake with mostly the default options still as they are. However, I left the config storage to iXVolume because I figured it's not something I need to be messing with anywhere other than in the UI for the app and there it was already working fine previously - and then I changed all of the other storage options to Host paths with a folder I've set up myself. (I should've made more folders for it in order to separate the pre-encoded from the re-encoded video files, but I just wanted to get it over with to see how it goes.) So I gave it a shot, and it works fine now. Well, kind of. I still can't see the HDDs folder, although I could at one point during my trials and errors but then it wouldn't give me access so I decided to try something else. But now the built-in view of "storage" in the app's UI can see the video files just fine, in a place where I can place them; because Applications isn't accessible (nor viewable) to place files in, which is where I'm guessing Handbrake had assigned as its "storage" pathway before. Anyway, lesson learned without too much harm done, that I'm gonna have to mix things up a bit to work with the updated electric eel version of truenas scale, since HexOS is still meant to be used with the version it came with during its installation. Thank you for the help! It did push me in the right direction.