The TrueNAS team is pleased to release TrueNAS 25.10.0.1!
This is a maintenance release that includes fixes to SMB shares, application management, cloud sync operations, and error handling.
25.10.0.1 Notable changes:
Fixes an SMB2 query directory with SMB_REOPEN flag issue (NAS-138259). Resolves an issue where client systems connected to TrueNAS 25.10 SMB shares could experience file access issues, including files appearing missing or shares showing as empty when browsing directories, media libraries (Plex, Jellyfin, etc.) losing access to files or removing them from indexes, and files failing to open or save over SMB.
Fixes VFS disconnect handling that prevented Time Machine snapshots (NAS-135813). Resolves a bug in the io_uring_vfs_disconnect function where walking the Samba VFS stack for smb_vfs_disconnect was terminating early, causing Apple Time Machine snapshots to fail execution. The function now properly traverses the full VFS stack without premature exit.
Fixes Docker service startup failures on systems with slow disk initialization (NAS-138232). Resolves a timeout issue where Docker initialization on HDD-equipped systems could take 2-3+ minutes, exceeding the default 120-second service timeout. This caused the apps service to be incorrectly marked as FAILED even though Docker eventually started successfully. The service timeout has been extended to 960 seconds (16 minutes) to accommodate slower disk scenarios.
Fixes custom application update failures from version 1.2.13 to 1.2.14 (NAS-138230). Resolves an issue where custom applications would fail to update properly, with multiple update attempts yielding no errors but the update notification persisting. The fix ensures that custom app versions are correctly upgraded alongside image updates during the application upgrade process.
Fixes false validation errors for custom app upgrades (NAS-138534). Resolves an issue where validation errors were incorrectly raised for custom apps during upgrade summaries when only the container image required updating. The system now properly recognizes that custom apps qualify for upgrade availability if either their images are outdated or catalog manifest changes exist.
Fixes Cloud Sync Task validation errors after upgrading to 25.10 (NAS-138281). Resolves an issue where Cloud Sync Tasks would display no available tasks after upgrade, with validation errors occurring when querying cloud sync tasks. The errors stemmed from Pydantic validation failures where parameters like chunk_size exceeded schema-defined limits.
Fixes a DNS validation typo in directory services (NAS-138364). Resolves a typo in DNS validation logic where “@” was incorrectly used instead of “.” as the separator between hostname and domain name.
Fixes ZFS error handling for paths with multibyte UTF-8 characters (NAS-138554). Resolves an issue where ZFS paths containing multibyte characters would generate corrupted error descriptions, causing Python’s Unicode decoder to fail. This resulted in simplified error messages instead of detailed ZFS exceptions and misclassification of error codes (EZFS_UNKNOWN instead of EZFS_INVALIDNAME), breaking dataset resolution APIs.
Fixes false temperature alerts for disks with negative threshold values (NAS-138028). Resolves an issue where disks with invalid or negative temperature thresholds would trigger persistent warning alerts in the GUI and automated email notifications. The system now properly filters out disks with negative temperature threshold configurations during alert generation.
Improves NetBIOS naming by expanding permitted identifiers (NAS-138390). Removes additional blacklist restrictions on NetBIOS names and workgroups, allowing more Microsoft-restricted keywords to be used. This change addresses customer environment needs where previously prohibited network naming identifiers are required.
I just downloaded the 25.10.0.1 update and installed it now. The SMB issues appear to resolved, and the Apps are starting up normally as expected. That was a painful three weeks.
With this blocking issue over, my next steps is to install two NVMe drives into my server, set it up as a drive mirror, and migrate my apps to some speedier storage.
I was able to execute a manual update, where there is a setting to put temporary files to memory device or the datapool, so I selected the datapool. Reporting still does not seem to work, I think my system dataset is somehow not set up correctly. It is an old setup, started out with FreeNAS 9.0, and upgraded through the years, migrated to Scale in April.
Thanks for providing this patch while we wait for the next release.
I was chasing a PC backups issue (SMB) for the last 2 months and it looks like it was not the backup software, but TN (first proper bkp done this morning after TN upgrade last night).
Backup software would run fine, and produce a bkp file, until the very last minute where the error was “the specified file cannot be found” and it would then delete the bkp file, and fail.
(have recycle enabled so I can catch any bkp deleted by error, bug or user/malware).
But thanks, I can use my time better again, but enough people will wonder:
How did this happen? (Reason for decisions/changes).
How did it pass QA? (New change so not enough test cases for SMB services?).
Jira is failing to log me in, so I can’t file a bug. I’ll post it here.
Failing to create Time Machine backups
After upgrading to MacOS 26.1 and TrueNAS 25.10, my Time Machine backups were getting corrupted. I think this is occurring because an SMB directory rename is failing with a “Permission denied” error. I was able to reproduce this error with a new Time Machine backup (starting with an empty Time Machine dataset on TrueNAS).
MacOS 26.1
TrueNAS 25.10.0.1
Steps:
On Mac, add a new Time Machine destination for TrueNAS (Mac Setting’s app → General → Time Machine). Add an encryption password for the backup.
Start the “Console” app on Mac. Hit the “Start” button to start capturing debug output.
In the Mac Time Machine setting, right click the TrueNAS destination and select Backup Now.
This will create a new backup directory ending in “.incomplete”
After initial setup, Time Machine will try to rename the directory to .sparsebundle
It will get an error code 13, “Permission denied”.
Time Machine backup will fail.
In the Console app, hit Pause to stop the capture.
In the search bar, search for “.incomplete” and hit enter. You’ll find the following errors. Clear the search bar to see the related SMB error.
Failed to rename ‘(Backup location).incomplete’ to ‘(Backup location).sparsebundle’, error: Error Domain=NSCocoaErrorDomain Code=513 ““(Backup location).incomplete” couldn’t be moved because you don’t have permission to access “Time_Machine”.” UserInfo={NSSourceFilePathErrorKey=(Backup location).incomplete, NSUserStringVariant=(
Using Mac Finder, I’m able to manually rename the .incomplete directory to .sparsebundle. I’m not sure, but this error could be related to this change:
wiki .samba.org/index.php/Samba_4.22_Features_added/changed#fruit:posix_rename
I think existing Time Machine backups are getting corrupted from the same error as the repro.
I’ve seen reports of MacOS client behavior change in some recent updates that breaks SMB protocol expectations. I believe the latest samba bugfix release tries to work around it. If so and if this is related then fix will maybe be in 25.10.1. FWIW I don’t see this behavior with my macs.
+ <para>When <parameter>fruit:ignore_zero_aces</parameter> is
+ enabled, attempts to modify filesystem permissions fail if the ACL
+ sent over the wire contains no ACEs. This is completely valid
+ client behaviour, but it means subsequently no further access is
+ possible to the file, unless permissions get fixed by an
+ administrator.</para>
+ <para>This problematic behaviour has been reported for latest
+ macOS versions and this new option allows to work around
+ it.</para>
Apparently in some cases MacOS will attempt to set an SD with no ACEs in the DACL (which obviously grants no access to the file) then reopen and perform operations. This is sometimes a bug people introduce in ACL handling for SMB protocol where a NULL DACL carries a significantly different meaning than an empty DACL array. A NULL DACL means wide-open. An empty DACL means completely shut. Both are valid and we can’t equivocate between them without a significant security issue.
The reason why we can’t equivocate between the two is that some software will intentionally set an empty DACL to create secure temporary files (write access maintained by having handle open already).
FWIW, the fruit:posix_rename feature was removed for a significantly important reason:
This option of the vfs_fruit VFS module that could be used to enable POSIX directory rename behaviour for OS X clients has been removed as it could result in severe problems for Windows clients.
The notes don’t go into details, but usually when protocol standards that other operating systems rely on get ignored you can end up with data corruption.
If you treat empty DACLs differently than protocol dictates you can end up with unintentional introduction of CVE for software packages that rely on the correct protocol behavior.
If you ignore protocol requirements about open files and renames then you can potentially end up with data corruption or significant client-side bugs from OSes that rely on correct behavior.
My Mac was running Time Machine backups fine for a while with macOS 26.1 and TrueNAS 25.10 , then eventually the backup got corrupted. Rolling back to a previous snapshot, didn’t help, because the next backup was also corrupted. I think once the backup gets to a state when it needs to rename files/directories, it might run into this problem. In the process of troubleshooting, I was able to reproduce this error with a new backup destination.
That’s your SMART crontab entry. Either delete these SMART tests, if you trust the TrueNAS built in disk health monitoring; or deal with the emails; or set them to silence the output (but then why run them)
So that task has been there since forever, but this is the first email about it ever, hence wondering if the update triggered it? Like are these emails going to be a regular thing because of the SMART UI removal or something?
No, that tasks gets automatically created when updating to 25.10 (source). You can set the hide output checkboxes to avoid the emails. That “fix” will also be done automatically in 26.04 (source).
“null” means that the command did not generate any meaningful output.
