This workflow automates the detection of OpenZFS CI failure detection via Gotify notifications !!
-
Notable changes:
- Updates the Linux kernel to the latest 6.12 LTS release (v6.12.91). This update mitigates several kernel vulnerabilities, including the Dirty-Frag local privilege escalation (CVE-2026-43284 and CVE-2026-43500), the CIFSwitch local privilege escalation in the CIFS client (CVE-2026-46243), a ptrace privilege issue (CVE-2026-46333), and the related Fragnesia privilege escalation in the ESP-in-TCP path (CVE-2026-46300). It also enables additional CPU side-channel mitigations.
- Updates Samba to version 4.22.10 to address multiple security vulnerabilities.
This Samba maintenance release resolves several CVEs, including a missing access check that let read-only users set or delete reparse point attributes (CVE-2026-1933) and a flaw in the WORM (Write Once, Read Many) module that allowed protected files to be overwritten by renaming a new file over them (CVE-2026-2340). See the Samba 2026 security release impact statement for the TrueNAS-specific impact assessment, or the Samba 4.22.10 release notes for the complete upstream list. - Fixes a potential double free when freeing blocks cloned after deduplication table pruning.
Blocks created through block cloning could be freed more than once if their deduplication table (DDT) entries had already been pruned, because the free path did not check the block reference table (BRT) first. - Fixes virtual machines stored on NFSv4.1 datasets failing to power on.
A change introduced in 25.10.2.1 could cause the NFSv4 change cookie to move backward after a file left the cache due to memory pressure, a remount, or a reboot. NFSv4.1 clients that depend on a monotonic change cookie, notably VMware ESXi, rejected the affected files. A virtual machine stored on an NFSv4.1-exported ZFS dataset then failed to power on with the error “The file specified is not a virtual disk.” This release reverts that change while a complete fix is finalized upstream. - Fixes a kernel crash in the iSCSI target layer during SCSI bus or LUN resets.
A use-after-free in the clustered locking path of the iSCSI target could crash the system during a SCSI reset, most often on Enterprise High Availability (HA) systems while a peer controller was leaving the cluster. The target layer now waits for lock teardown to complete before releasing the associated memory. - Improves iSCSI LUN replacement during High Availability failover.
On Enterprise HA systems, cleanup of a replaced LUN could stall during failover while a peer controller was being evicted from the cluster, which blocked later LUN replacements. Cleanup is now held until the cluster coordination it depends on has finished. - Fixes a validation error that blocked static network configuration on some High Availability systems.
On HA-capable systems, saving a static network configuration could incorrectly fail with “Enabling DHCPv4/v6 on HA systems is unsupported” even when DHCP was not being enabled. This affected fresh installs before any interface had a saved configuration. The check now triggers only when DHCP or IPv6 autoconfiguration is explicitly enabled. - Improves Active Directory rejoin, reset, and recovery handling.
This release hardens the Active Directory rejoin and directory services reset operations, improves domain controller selection on systems with more than one available controller, and produces clearer diagnostics when a join or authentication problem occurs. - Fixes ZFS automatic snapshots not being created after a Time Machine backup until the Mac reconnects.
When a Time Machine SMB share has automatic snapshots enabled, recent macOS versions (Tahoe and later) sometimes keep the SMB session open after a backup completes instead of disconnecting, which prevented the post-backup ZFS snapshot from being taken until the client reconnected or restarted. The snapshot logic is updated to handle these persistent Time Machine sessions. - Reduces excessive winbind log messages for failed user and group lookups.
When Active Directory is enabled, looking up a user or group that does not exist (for example throughgetpwnamorgetgrnam) generated a warning for every failed lookup, which could rapidly fill the winbind log. These messages are now logged at informational level instead of as warnings.
https://www.truenas.com/docs/scale/25.10/gettingstarted/versionnotes/#25.10.4
-
My home server configuration:
The server runs TrueNAS SCALE (release 26.0.0-BETA.1) on an AMD Ryzen 7 PRO 8845HS, with 32 GiB of memory and no swap configured. Alongside ZFS it hosts a substantial collection of services including Portainer-managed containers, immich, Forgejo, FreshRSS, Jellyfin an automation platform, several PostgreSQL databases, an identity provider, and a number of smaller tools. At the moment of measurement, the operating system reported the following:
total used free buff/cache available Mem: 30Gi 27Gi 1.2Gi 3.8Gi 3.3GiUptime stats:
The following figures come from
/proc/spl/kstat/zfs/arcstats, accumulated over an uptime of 53 days:Metric Value ARC size 5.04 GiB ARC target (c) 5.09 GiB Maximum (c_max) 29.68 GiB Minimum (c_min) 0.96 GiB L2ARC none configured The hit and miss rates, derived from the raw counters, break down as follows:
Access class Hit rate Miss rate Overall 96.4% 3.6% Demand data 98.05% 1.95% Demand metadata 97.91% 2.09% Prefetch data 6.0% 94.0% Prefetch metadata 66.9% 33.1% Live view of hit/miss performance:
Because the counters above are cumulative since boot, they represent an average spanning nearly two months and cannot, on their own, describe the system’s present behaviour. To capture that, I sampled the cache once per second under active load using
arcstat:time read ddread ddh% dmread dmh% pread ph% size c avail 22:23:43 949 867 98.8 77 98.7 5 0 5.3G 5.3G 118M 22:23:44 668 384 97.7 284 100 0 0 5.3G 5.3G 425M 22:23:45 1.5K 1.1K 98.5 432 100 39 2.6 5.3G 5.3G 367M 22:23:46 686 421 98.6 248 100 17 0 5.3G 5.3G 344MWith reads peaking at roughly 1500 per second, the demand-data hit rate held steady at approximately 98% matching that of the uptime, thus confirming that the long-term average is not concealing a recent decline in performance. The cache is presently serving requests just as effectively as it has, on average, throughout its uptime.
ddh% : Demand-data hit
dmh% : Demand-metadata hit
Stats were obtained from
/proc/spl/kstat/zfs/arcstats, with live sampling viaarcstat.The equivalent figures are available on FreeBSD under
kstat.zfs.misc.arcstats. -
RAM prices are getting high, so I set up a self-hosted price tracking service called PriceBuddy to monitor specific products on Amazon.de, Amazon.com, and Geizhals.
I also built a SeleniumBase scraper to parse data from the Geizhals website.
-
Happy testing fellow geeks.
-
-
One line of code can change a bunch of failed CI matrix runs!!
-
For roughly a year, my phone, laptop and desktop relied on the Tailscale-Mullvad integration to route traffic through Mullvad’s VPN. The add-on cost 5 dollars a month.
That configuration ended when my credit card got rejected and cancelled twice. So I moved to paying Mullvad directly by SEPA for 12 months.I replaced the add-on with a self-hosted equivalent on my TrueNAS server. The stack consists of two containers managed through Portainer:
- mullvad-exit-gw runs gluetun configured with a Mullvad WireGuard endpoint in a city and country of my choice.
- mullvad-exit-ts runs tailscale and advertises itself to the tailnet as an exit
node under the hostname mullvad-de. The Tailscale container shares a network namespace with the gluetun container via network_mode: “service:mullvad-exit-gw”. All traffic from the Tailscale sidecar,
including its connection to the Tailscale coordination server, therefore leaves the host through the Mullvad tunnel. On any tailnet client, the command tailscale set –exit-node=mullvad-de –exit-node-allow-lan-access routes outbound traffic while preserving access to the local network. Persistent state for Tailscale lives on a host bind mount at
/mnt/zfs_tank/Applications/tailscale-mullvad rather than a TrueNAS-managed ix_volume. This allows the stack to survive a Portainer reinstallation without forcing a fresh device authorization.
Fixing a DNS leak
The initial deployment passed Mullvad’s IP check but failed its DNS check, with the result reporting Cloudflare resolvers in the city I chose. The cause lies in gluetun’s default behavior: it operates its own DNS-over-TLS resolver, and that resolver uses Cloudflare upstream unless directed otherwise. The VPN tunnel was correctly configured, but the resolver running above it bypassed Mullvad entirely. Two environment variables on the gluetun container correct this:
DOT: “off”
DNS_ADDRESS: “194.242.2.4”The address 194.242.2.4 is Mullvad’s anycast resolver with content filtering for ads, trackers, and malware domains. I also configured the same resolver as the tailnet’s global nameserver in the Tailscale admin console, ensuring that any device routed through mullvad-de performs DNS lookups through Mullvad rather than its local resolver.
