Issue with LDAP


  • Used Zammad version: 3.6
  • Used Zammad installation source: package
  • Operating system: CentOS

Hi community !

I have an issue while I try to log into Zammad. In the production.log file I see these issues :

INFO -- :   Parameters: {"username"=>"username", "password"=>"[FILTERED]", "fingerprint"=>"-999999999"}
INFO -- : ldap authentication for user 'username' (samaccountname) successful!
INFO -- : Can't connect to ldap backend PG::DataCorrupted: ERREUR:  n'a pas pu lire le bloc 45467 du fichier « base/16385/17367 » : a lu seulement 0 octets sur 8192

The LDAP server works fine, the issue appears only since today.

Do you know how can I solve this issue ?

It looks like something is wrong with your PostgrSQL server (PG::DataCorrupted), the path seems to be part of postgre’s storage structure; base/16385/17367.
Maybe your postgresql log’s might tell you more about the issue. You could try to restart postgresql and see if it recovers. If those data files are really corrupt, and you’re still able to connect to postgres and read data, make sure to make a backup before you restart

1 Like

Hi @olafbuitelaar ,

Thanks for your reponse.
Is this table ‘base’ a standard table ? Do you think it’s possible to reinstall Zammad to retrieve the lost data ? Or maybe antoher installation for getting the data of this table ? I still have access to the postgres instance, so I could export and import data within it.

Hi @LSA,

base is part of the standard storage layout of pgsql, so it doesn’t refer to a specific table, see;

Also i’m not sure if this pgsql instance is from your zammad, or if your ldap service uses maybe pgsql as a storage backend.

Usually when pgsql complains about currupted files, the instance could be considered lost and one should recover from a backup. You might be lucky and postgresql could fill on the blanks from it’s WAL logs after a recovery.

I don’t think you need to reinstall zammad, you just need to recover you postgresql installation

1 Like

Hi @olafbuitelaar,

I have restored the specific file shown in the logs from a backup and voilà it’s working very well again !

Thanks a lot !

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.