Error change Server-Password via Cron

Hi!
I get from all Univention-Systems the following Cron-Message every Day:
failed to change server password for cn=bdc,cn=dc,cn=computers,dc=intern,dc=domain,dc=lan

I found The following Messages in /var/log/univention/server_password_change.log:
Starting server password change (Fri May 8 01:01:25 CEST 2020)
Proceeding with regular server password change scheduled for today
run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/portal-server-password-rotate prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-admin-diary prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-directory-manager-rest prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-libnss-ldap prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-s4-connector prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba4 prechange
Permission denied.
run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server nochange
File: /etc/listfilter.secret
Multifile: /etc/postfix/ldap.distlist
Multifile: /etc/postfix/ldap.groups
Multifile: /etc/postfix/ldap.external_aliases
Multifile: /etc/postfix/ldap.sharedfolderlocal
Multifile: /etc/postfix/ldap.virtualwithcanonical
Multifile: /etc/postfix/ldap.virtual_mailbox
Multifile: /etc/postfix/ldap.sharedfolderremote
Multifile: /etc/postfix/ldap.sharedfolderlocal_aliases
Multifile: /etc/postfix/ldap.virtual
Multifile: /etc/postfix/ldap.canonicalrecipient
Multifile: /etc/postfix/ldap.transport
Multifile: /etc/postfix/ldap.canonicalsender
Multifile: /etc/postfix/ldap.saslusermapping
Multifile: /etc/postfix/ldap.virtualdomains
run-parts: executing /usr/lib/univention-server/server_password_change.d/portal-server-password-rotate nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-admin-diary nochange
89a96eca-9054-4dd3-8828-a402f4a53916
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-directory-manager-rest nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-libnss-ldap nochange
File: /etc/libnss-ldap.conf
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-s4-connector nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba4 nochange
failed to change server password for cn=bdc,cn=dc,cn=computers,dc=intern,dc=domain,dc=lan

I can execute /usr/lib/univention-server/server_password_change.d/univention-samba4 prechange manualy without errors. (After this execution I run the Script with nochange)

The permissions of univention-samba4 are the same as the other file in the Directory, and the Cronjob run the Scripts as root.
I get the same error message by running /usr/lib/univention-server/server_password_change

I use Univention 4.4-4
Thanks for a hint …

Hi @morfey

I get the same message since a week or so.

Could you resolve the issue?

Best, Bernd

Hi Bernd!
No! The problem isn’t solved! Do you have a solution?
Best Regards!

Hi @morfey

there are two new bug-reports: https://forge.univention.org/bugzilla/buglist.cgi?quicksearch=server_password_change&list_id=153889

So the issue seams to be known but there is no solution until now.

Best, Bernd

Hi @morfey,

maybe of interest for you too: Failed to change server password

Remember to execute the command on the master-server (so not the servers reporting the issue in the first place)

Best, Bernd

Mastodon