Happened again with Disable AD User / Group Cache checked… so that doesn’t fix it either.
So I CANNOT have this continue to happen… so I switched the Active directory backend to AD which appears to not even work as nothing gets mapped into it’s range reason but YAY … because that means it ALWAYS falls though to TDB to resolve my groups… so at least my IDs always map the same on on this device. I modified my shares to always use groups that TDB is resolving already so … I think this will continue to work fingers crossed
I have no idea how this is so completely broken that this occurs at all it seems that sometimes RID was failing to map some of my groups so TDB was picking them up occasionally and causing the group ID mapping to randomly change.
Why can’t I just use plain LDAP authentication to the domain controllers anyway and not even try to be fancy??? I just need it to work. (Truenas wont’ let me do that even though plenty of other appliances do eg proxmox).
Hmm perhaps. It’s nearly time for me to upgrade anyway.
I also just got this on when stripping permissions on one of my shares to correct them… it appears I cannot strip or save ACLS there for some reason.
Error: Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 509, in run
await self.future
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 556, in run_body
rv = await self.middleware.run_in_thread(self.method, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1367, in run_in_thread
return await self.run_in_executor(io_thread_pool_executor, method, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1364, in run_in_executor
return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.11/concurrent/futures/thread.py”, line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/schema/processor.py”, line 183, in nf
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/schema/processor.py”, line 55, in nf
res = f(*args, **kwargs)
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/plugins/filesystem/acl.py", line 890, in setacl
return self.setacl_nfs4(job, data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/plugins/filesystem/acl.py", line 602, in setacl_nfs4
self.setacl_nfs4_internal(path, data[‘dacl’], do_canon, verrors)
File “/usr/lib/python3/dist-packages/middlewared/plugins/filesystem_/acl.py”, line 554, in setacl_nfs4_internal
raise CallError(setacl.stderr.decode())
middlewared.service_exception.CallError: [EFAULT]
I vaguely recall this traceback occurring if a user removes all inheritable ACLs on a recursive operation (invalid ACL that wasn’t caught in validation).
So, attempting to force it to just always fall back to TDB did not work, some users would not resolve… not sure why. I even created a copy of a working user and that was broken also.
Messing with the ldmap entries resulted in it failing to clear the IDMAP configurations and reset them to defaults when leaving the domain and re-adding it so I could not get back to a working state, so I went to the previous boot environment and was able to get back to working there. It kept coming back with broken idmap configs that did not match what was in smb4.conf… which opening it appeared to be correct the main issue was the domain name in the GUI for the SMB primary domain was no longer blank… which seems to have broken it, and it could not be edited back to blank from the UI it seems there is some erroneous blank checking on save for that field.
Truenas is the only system I have that has any Active Directory issues and its baffling.
It also appears that Truenas does not follow the published examples of configuring tdb first, the the other backends after in the config file I am not sure if this can cause an issue but it is noteworthy i think.
Upgraded to FangTooth and I am almost certain it still has the same issues.
I still have users/groups mapped into different ranges via RID and TDB… the behavior seems to be identical to what was occurring on Electric Eel and before.
There is 1 domain added to the system and you can see I have entries from TDB and RID for the SAME group at the SAME time that isn’t supposed to be possible is it? Also usually when it breaks it stays broken untill I remove and readd ACLs to the share and then the IDs from TDB show up also (9xxxxxxxx)
