Clevernickname

Ah, I actually had multiple issues, but it depended on the share: 1) Some shares, I could read dirs/files, but not do anything else 2) Some shares, I could not access at all (same problem as you, I think?) 3) Some shares I could read and add new files, but could not make changes. Since I backup my families machines to the array (and then sync those folders to cloud), that meant that changed files where not being backed up. I'm baffled on why the above occurred and why it was not consistent when it failed. So far, I've got everything working again with AD. I did see odd error messages in the logs when this happened, but I did not think to save them. Something about the access belonging to multiple ids.

I found this post while searching for solutions. After messing around a bit, this worked for me. Took a long time however. WARN - this could really mess up your file permissions. This worked for me, but might not work for you. 1) Use WinSCP to reset permissions on your shares and all files in those shares to your Domain Administrator account. If the domain/user don't show up in WinSCP, it probably means unraid isn't connected. It might also mean that you changed the default owner in the settings to something else. WinSCP has a checkbox to apply to children; you'll need to check that checkbox. 2) You should then be able to use your domain admin account on a windows box to set the correct owners for the files/directories. I use groups. One for read access (groupname-R) and one for write access (groupname-RW). I also leave the administrator account as full access; otherwise, I won't be able to change permissions using that account. While #1 is pretty quick, #2 was really slow for me. I'm all done now, but I've been working through this for a couple of hours. I have no idea why all of the permissions where lost after upgrading; my groups where still assigned, but the files where owned by something else.

Interesting. I just checked my logs and I don't have any instances of those. I wonder if our setups are different enough that it doesn't occur for me? My logs only go to back 7/16/2021, but I don't have that error message at all. I have a 2019 AD server with failover to a secondary; Both unraid boxes are joined to the AD server and all share access is managed by AD. Both are setup to log to seq (https://datalust.co/seq) with seq running the syslog plugin.

Edit: 0 errors in the last 8 hours on both of my unraid servers after making this change; I'd say this did it. I used to get hundreds or thousands of these messages a day. All my file shares still work, and AD security is being respected as well. ---- Alright, this seems to have done the trick for me as well. I get a lot of these through out the day, so I'll check my log file again tonight.

I'm not really familiar with samba at all, but based on the idmap source code here - https://github.com/samba-team/samba/blob/master/source3/winbindd/idmap_hash/idmap_hash.c And a couple of commits around it, it sounds like we shouldn't have this in our configs anymore idmap config * : backend = hash idmap config * : range = 10000-4000000000 That being said, I don't know what to replace it with. It looks like it's being used to hash a AD userid to a unix userid? https://marc.info/?l=samba-technical&m=148768565527552&w=2 EDIT: Ok, yes this is the problem. I've no idea at the moment how to work around it though. See: https://www.samba.org/samba/docs/current/man-html/idmap_hash.8.html

I believe Samy traced his problem to an issue with his MikroTek router, not something on Unraid himself. I'm getting this error constantly, but I'm not using a MikroTek router, so my cause must be something else.

My syslog server is hammered with these as well - All of the messages appear to be this: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba I can provide the logs or diagnostics as needed.