**LDAP client internal error (AccountProvider_Error_82)**

System version
NethServer release 7.6.1810 (final)
Kernel release

LDAP client internal error (AccountProvider_Error_82)

I have ended up with the above error twice now.

  1. The first time I tried to restart the nsdc service and the service stopped but would not restart. I rebooted the server and it came right. The shutdown took forever though.
  2. The same happened today but a reboot did not fix the issue this time.

The common aspect of both events was that I was changing the system time. The time was out even though it was set to NTP so I set it manually. Today I had to reset the time since I was 24 hours out. However I cannot be sure that LDAP error happened near to the time I changed the date/time.

So in the mean time everyday functionality is still there but the users and groups screens have empty tables.

Any ideas please on how to proceed to restore access to my users and groups?


On the server where the Samba4 account provider is installed, this is a tricky one. If restarting the NSDC service doesn’t fix this, you probably need to reinstall samba4 accountprovider and recreate all users.
I have ran into this in the past too: Another AccountProvider_Error_82
A search on the forums gives you several discussions with the error_82 problem: https://community.nethserver.org/search?q=error_82
I hope there is another way of solving this because IMO it is a bit of a bomb under the confidence and stability of NethServer.

Thanks Robb - somehow all is normal when I log in this morning - so I will leave this thread open for a while and hope that all is good!

If it does come to reinstalling the samba4 accountprovider I am wondering how that works - if you effectively remove it it sounds like you would have no account to carry on working with?

Partly correct: all Samba4 4 accounts will be gone and have to be recreated afterwards. During reinstall admin and administrator accounts will be recreated.
For the rest: all local (linux) accounts will remain available. You will not loose your root account of the server by reinstalling Samba4 AD accountprovider.

But this should be a very last resort. IMO it should be avoided to recereate all accounts (and userrights). Corruption of the Samba4 AD userbase should not happen in the first place. It would be a good thing if more about this specific ‘bug’ is known. It would be good to know where it comes from and how to repair it (without reinstall) Although I do realize that this error code probably is a very generic message and could point to numerous possible problems.

(Sorry I don’t try to hijack your post @johnd, but I have the same error)

I upgrade the NS and I got this error in the Dashboard then disappear and show an error related to my “password policy”

Then I see in this section “Domain accounts” than only shows “one” part, and the other part just says “JOIN ok”

I’ll restart again… but I’m biting my chair.


– Note1, i can’t restart, the VM looks “hanged”… need to stop the VM from then proxmox console.

– Note2, after the forced stop and restart in the proxmox I see the full info in “Domain accounts”:

This is the SECOND time (previously the past week, and this was after another upgrade) that I need to stop the VM from proxmox after trying to “Reboot” from the Dashboard in NS.

– Note 3, someone notice the “weird” date time, right now our date is 02 May, and after the reboot it shows 03 May !!

Then I go again to the Dashboard, the time is right, but again the second part disappears in Domain accounts:

I just cross my fingers that this is “ok”… but I need to be sure, I will reboot my own PC to see if I can get into our ERP without issues. :sweat:


– Note 4, I can work on the ERP (need domain authentication) so tomorrow I still have a job :thinking:.

– Note 5, the quick message with the same error appears in the Dashboard again.

And yes, I still can use this RSAT tool,

(Need to be worried?)

Today Friday, all looks working again.
I believe that Samba in NS, needs to refresh something (a database) after being updated (and maybe when restarting the server), in such cases is when I see things looking odd.

I really like to know what log need to read to see if this happening so I can have a little peace of mind. Any guess? (I check some logs, but I don’t know what/where to search)

I have not been taking very much notice of what is happening here since I have a 3 day weekend these days!
I will see if I can find some interesting stuff in the logs tomorrow at some stage.
What I do know from looking at the logs last week is that it took about 6 hours from when I changed the time until the errors were gone - and things were right when I returned to work the next day.


Messages that come up in the messages log are:

Apr 30 16:26:31 NethServer httpd: [ERROR] NethServer\Tool\UserProvider: LDAP client internal error (AccountProvider_Error_82)
Apr 30 16:26:31 NethServer httpd: [ERROR] (82) GSSAPI Error (init): Unspecified GSS failure. Minor code may provide more information#012Ticket not yet valid

Repeated every couple of minutes for a while.


This is a Kerberos ticket time error message. IIUC you have a local ad accounts provider, right?

Do you run NS7 in a VM? What is your hypervisor?

  • Please ensure the system clock is set correctly
  • Remove any credentials cache file: /tmp/krb5*
  • Try again
1 Like


Had a similiar issue after an update a while ago. Reboot did NOT help.

What worked was deinstalling the Accounts Provider (Make sure you have a valid backup or two!!!) then restore the last config-backup. That reinstalls the Account Provider, and keeps the data (user & groups).

Afterwards, all accounts and Groups where back there!

Your mileage may vary…


Maybe need more RAM, as @davidep suggest here ?


1 Like

This is why I wonder if:

That make me think if ‘rebooting’ when there is ‘something’ being updated can damage that ‘something’.
I need to know when I can reboot without creating more issues after an update, how to know such thing?

Thanks David,
To answer your questions:

  1. I do have a local AD accounts provider.
  2. I do not run Nethserver in a VM (although I probably should be).

As mentioned above I am up and running again with the users and groups pages populated. However there does seem to be an issue in that 6 hours after a time change seems a long time to wait.

1 Like

Sorry for my confusion!

Please mark the topic solution: Howto mark a topic as solved

Ok - I will mark as solved. I was leaving it open for a while since it is solved in the sense that all is working again - but it is not solved in terms of what caused the problem and I suspect it would happen again if I changed the date/time significantly (I don’t want to try!!)

…if that happens again :wink:

1 Like

Do I understand this correctly that this has been caused because of a timestamp fckup?
I know Samba4AD/Kerberos is very sensitive for timestamps. So is native MS AD.
What would be needed to not have such a problem in the future? Is that a matter of always (only?) use the domaincontroller as timeserver and make sure it is always available to sync with?

1 Like

Noted - and thanks for your help David.

1 Like

My evidence is somewhat circumstantial but it does seem that time changes were the issue. Twice I changed the time and the issue happened each time - but exactly when it happened I am not sure since I was unaware of the possible connection. I am aware of time issues with MS Windows AD but it just hadn’t clicked.