Running 25.10.0.1 - Goldeye, still getting this. When updating I had to rejoin the domain and then fix permissions on the data sets, but it is still happening.
Iām still having this issue with 25.10.0.1 - Goldeye.
I have to rejoin the domain almost every day.
I only have 1 DC.
Iāve been running four servers in different locations, starting with version 24. Now two are running 25.10.0.1 Goldeye. Those are the ones experiencing issues.
After trying some of the recommended workarounds/fixes, they both show as Healthy in Directory Services, but at least once a day the Active Directory users and groups disappear. One server also has the SMB service stop.
Unfortunately it seems this is still a tricky problem, despite the latest updates. Itās a daily chore to check if everything is OK. I also tried adding the following to the cron as an attempt to refresh the cache a couple times per day:
0 */12 * * * /bin/midclt call directoryservices.cache_refresh
Hi, still on 25.04.1 here and facing the same issue and I want to post my workaround until things get more stable.
I created a keytab with a dedicated domjoin-user and put the kinit into rootās crontab. Works fine since weeks.
ktuil
addent -password -p domjoin@XXX.XXX -k 1 -e aes256-cts-hmac-sha1-96
wkt /root/ktab/domjoin.keytab
crontab:
30 */5 * * * /usr/bin/kinit -kt /root/ktab/domjoin.keytab domjoin@XXX.XXX > /dev/null 2>&1
I discovered one of the issues here is that, even with everything else correct, truenas generates invalid krb5.conf files if there is an ipv6 address associated with the kdc.
this in turn, leads to inability for it to authenticate.
So if there is an ipv6 address associated with the ad servers, it will generate a krb5.conf file that looks like this:
ā¦
[realms]
DBERLIN.ORG = {
default_domain = DBERLIN.ORG
kdc = 192.168.1.33
kdc = fd00:dead:beef:0:7724:88e0:6ded:5009
}
ā¦
this will then error like so:
root@garage-backup[~]# kinit foobar@DBERLIN.ORG
kinit: Invalid argument while getting initial credentials
The issue here is that ipv6 addresses in krb5.conf must have square brackets around them:
from the man page of krb5.conf:
kdc
The name or address of a host running a KDC for the realm, or a UNIX domain socket path of a locally running KDC. An optional port number, separated from the hostname by a colon, may be included. If the name or address contains colons (for example, if it is an IPv6 address), enclose it in square brackets to distinguish the colon from a port separator. For your computer to be able to communicate with the KDC for each realm, this tag must be given a value in each realm subsection in the configuration file, or there must be DNS SRV records specifying the KDCs.
If the IPV6 addresses are changed to conform correctly (or you remove the IPV6 addresses of the kdc), by placing them in square brackets, it all works again, until it rewrites krb5.conf and breaks it again.
Unfortunately, the bug tracker is down but iāll report this when itās back up.
This bug is NAS-139734 and hopefully should get fixed in 25.10.2 (There are PRs out for it).
I suspect this is the cause of a bunch of the preauth failures in this thread, especially those that started with 25.10 (which is when they started figuring it out automatically and filling the IP addresses)
One workaround: Edit the realm in advanced and specify the KDC servers manually, and it will use those instead of generating a broken krb5.conf.
Apologies in advance as Iām coming to this a bit late.
I recently upgraded two of my TrueNAS servers from Electric Eel 24.10 to Fangtooth 25.04.2.6. I started with the replication target which went smoothly so after a couple of weeks I proceeded with upgrading the primary system. Unfortunately that experience wasnāt quite as straightforward and the AD integration broke during the process. After some reconfiguration (leaving and rejoining the domain) I was able to get things working again.
However today Iāve had a report from a user who was unable to access their share and it appears that AD has faulted again.
The main reason for my post is to better understand how an issue with this level of impact which seems to have been reported as far back as May 2025 is still unresolved without moving to 25.10 particularly when that version is not yet marked as āMission Criticalā in the TrueNAS software status.
Iād also be interested to hear how enterprise customers have approached this. Did they move to 25.10 while it was still in beta or were any interim fixes or patches made available to them?
Perhaps naively I had assumed that āMission Criticalā would indicate that issues of this nature had already been addressed in earlier releases. Maybe this version should never of reached āMission Criticalā status or perhaps a patch should have been issued for this version.