NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
McLukic
Jun 22, 2016Star
RN 104 / OS 6.5 : AD group membership not synced for some users
Dear Communitiy members,
I started having an issue (or I just began noticing it, more realistically) regarding how changes in AD memberships are synchronised in the ReadyNas.
Of course AD mode is enabled, we get no errors when user list is imported manually using the web admin page, and for a majortiy of the users the changes in AD group membership are immedialtely reflected when a sync is performed.
But for a number of users it doesn't work. Let's say I update users A, B and C and put them into (or remove from) several groups on the AD.
I then perform a sync on the ReadyNas, and when I issue "id -Gn <username>" on the command line, I see that users B and C have their group memberships updated, whereas A still have the same groups.
Putting back the auth mode to "local" and setting it to AD mode again does not solve the issue : user A still has the same groups it had before the operation. Which makes me think there is a sort of "lock" on the NAS which prevents the user properties from being updated, and without yielding any (easy to see) error.
In my example users A B and C could be in the same OU on the AD, and I can't seem to find any difference between the users accounts which have the issue and those which don't.
Has anyone experienced the same problem or knows a workaround/solution ?
Thank you very much !
Dear all,
I am a bit disappointed that noone offered a structured solution for this issue.
It seems that I was able to fix it myself. Here is what I did (please note that I lost the permissions on my shares ; this is not an issue since we know precisely what to set and how but otherwise it could have been a real problem) :
(Some steps are maybe totally useless but I list them anyway)
- Set Authentication back to "local"
- Reboot device
- Once the device is restarted, SSH to it and :
systemctl stop winbind systemctl stop smb net cache flush rm -f /var/lib/samba/*.tdb rm -rf /var/cache/samba/* systemctl start smb systemctl start winbind
- Reboot the device
- Once the device is restarted, in the Web Admin page, set Authentication to ADS again (with the standard options, i.e. "do not cache ADS accounts" NOT ticked
- Restart the device
--> Changes in group memberships reflected in the outputs of for instance "id -Gn <username>" within 5 minutes
--> AD syncs launched from the Web Admin page do not yield errors anymore, new groups and users are visible and usable in the UI (to set permissions etc...), and objects removed from the AD are also deleted
So, after months of despair, the 6.5.1 update finally seems to solve the AD issues and we can finally plan to use the device in production.
It's great that at my company we can wait 6 months or one year to implement projects we were supposed to finish within one week, it allowed us to wait "a bit" until a proper firmware is released !
3 Replies
Replies have been turned off for this discussion
- BrianL2NETGEAR Employee Retired
Hi McLukic,
We had AD issues with the 6.5.0 firmware and NETGEAR have released the official firmware 6.5.1 to address it. I hope you can give it a try and update this thread with the result.
Kind regards,
BrianL
NETGEAR Community TeamHi,
Thank you for this information. Great that the 6.5.1 update is out, I did install it but it does not solve the problem.
In fact for some of the user accounts which had the issue, their group membership was immediately updated.
However now, there are still users for which the problem persists.
To be more precise,
- The ADS account refresh yields an error every other time (that is really it : one error, then the next try is a success). In one case the ads.log shows following lines :
[16-06-23 10:04:33] 2753 rndb_account.c:2264 error: Error. Fail to insert $home_folder/$user/$group/$group_has_user: Internal DB error. (2245:19:UNIQUE constraint failed: $group_has_user.user_id, $group_has_user.group_id) [16-06-23 10:04:33] 2753 rndb_account.c:2407 error: rndb_ads_account_import() ==> 3 (8614ms) [16-06-23 10:04:33] 2753 rndb_api.c:956 error: rndb_import_nolock() ==> 3 (8617ms)
In the case of a "2nd attempt" there is nothing unusual in ads.log.
- Some "user account" infos are not correctly updated : When I issue following command on some users
id -Gn <username>
the group memberships stay the same and are never updated (I tried for several users, including some for which there wasn't any issue before).
I'm at a loss as to what could be the problem and how to have the sync function correctly...
Thanks to anyone would could help me !
Dear all,
I am a bit disappointed that noone offered a structured solution for this issue.
It seems that I was able to fix it myself. Here is what I did (please note that I lost the permissions on my shares ; this is not an issue since we know precisely what to set and how but otherwise it could have been a real problem) :
(Some steps are maybe totally useless but I list them anyway)
- Set Authentication back to "local"
- Reboot device
- Once the device is restarted, SSH to it and :
systemctl stop winbind systemctl stop smb net cache flush rm -f /var/lib/samba/*.tdb rm -rf /var/cache/samba/* systemctl start smb systemctl start winbind
- Reboot the device
- Once the device is restarted, in the Web Admin page, set Authentication to ADS again (with the standard options, i.e. "do not cache ADS accounts" NOT ticked
- Restart the device
--> Changes in group memberships reflected in the outputs of for instance "id -Gn <username>" within 5 minutes
--> AD syncs launched from the Web Admin page do not yield errors anymore, new groups and users are visible and usable in the UI (to set permissions etc...), and objects removed from the AD are also deleted
So, after months of despair, the 6.5.1 update finally seems to solve the AD issues and we can finally plan to use the device in production.
It's great that at my company we can wait 6 months or one year to implement projects we were supposed to finish within one week, it allowed us to wait "a bit" until a proper firmware is released !
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!