This path obviously does work, because you are only going through 25.04 briefly to get to 25.10. When 25.10 is out and when you’ve decided to upgrade, go in two steps, from 24.10.
Don’t touch VMs after first upgrade and go directly to second, then migrate VMs.
It adds minutes to the upgrade window, and is overall safer in TrueNAS land.
Yep, that is still the case. Annoying I know, but tends to only be seen by developers. We are in process of switching from an un-versioned API to a versioned. Only the versioned API methods are being auto-populated in the docs at the moment. That will change as the year goes on and we expect to hit 100% conversion to fully versioned API.
Long term this will be much nicer as the situation now and always has been that APIs could randomly change between releases, which wasn’t good for developer types. But we’re still in that transition period. Bear with us
Emailing from the shell changed in 24.10, but Joe’s Multi-Report proved that it could still be done, just not the same way as before.
As you’ve discovered your previous script handling auditing tweaks won’t work in 25.04, but it’s been noted that it can be done in a different way, within the TrueNAS API.
Hopefully you will take some time to look at it.
If you conclude that it can’t do what you need it to do (albeit in a different way compared to how you used to do it) you may get some traction posting a feature request. I doubt iX will revert their changes, but perhaps they can offer extended API functionality to cover your use case, or something similar - given a well motivated request.
I’d suggest treating this as a Feature request and describing your set-up and needs so we have the information. we then get to see who else has the issue.
We will provide information about upgrade paths and issues, but right now the focus is on stability for Fangtooth.
Agreed… if you are conservative or mission critical, follow our software status page advice and wait for confirmation on VMs. We don’t want updates to cause issues and so you need to be “conservative”. In reality, “mission-critical” users need test systems and a support contract.
I have a virtualization truenas scale on proxmox. I recently installed the fangtooth 25.04-RC.1 from 24.10.2. After rebooting the network interface would not come up. I am using vmxnet3 driver for the system. Using this driver it has been working for a few years now but the interface fails to come up on 25.04-rc.1 and works fine if i boot in 24.10.2 or eariler. If i change the driver in proxmox to VirtIO or intel E1000 they system come up correctly in 25.04-rc.1. any thoughts as vmxnet3 has better performance.
Wowsers, thanks so much for the detailed testing, as someone with 2x W11 VM’s I will now just wait for release and hope that addresses some of these issues.
How does Fangtooth handle custom Docker apps? I have a few that are declared through yaml pasted into the interface, and a couple (Bitwarden self hosted and Sentry self hosted) that I had to do outside the web interface because they seed images and volumes using shell scripts and manage their own upgrades.
Several that use the “volumes” root level section to declare external named volumes in the docker/volumes folder on the apps dataset, which either the app’s supplied scripts created, or I had to create myself using the docker command.
All of these non-ui managed setups use Docker Compose, but at least Bitwarden wants to run the compose up itself, and Sentry has at least an .env file in its staging folder, and mounts a couple of read-only volumes from its own folder to supply configuration files to several of its containers.
How badly am I boned by inflicting this on myself, and how badly will Fangtooth break it?
Does anyone have issues with TimeMachine shares on Fangtooth RC.1? I moved from BETA to RC.1 yesterday and now I get a “The selected network backup disk does not support the required capabilities.” when TimeMachine tries to access the share. MacOS also went through an update and is now at 15.3.2.
There is one edge case some users hit where they had configured multi-protocol NFS shares. Properly supporting this requires disabling SMB2/3 leases globally, which prevents being able to use time machine.
This should probably be explicitly called out in the release notes. If you ever used the multi-protocol NFS share in the past then your time machine backups will start failing without a useful error message.
If my case I tried NFS briefly when I first installed TrueNAS but have since disabled NFS. I had one minor share configured as mult-protocol and it took me a bit to figure out why time machine started failing about installing RC1.