The file is now owned and therefore writeable by the listener, it was owned by the root user before. The sqlite3.OperationalError: attempt to write a readonly database error from the listener log should not occur anymore after you restarted the service, is that correct?
You should now probably follow the advice from my colleague and retry to do changes with the high listener debug level OX / UCS Authentication against ldap server failed
Hi,
sorry for reopening here, but unfortunately i have experienced the same issue again now.
I understood, that a rejoin will result in a new machine.secret file.
But does anyone have an idea why, although ucr get ox/cfg/authplugin.properties/com.openexchange.authentication.ucs.bindPassword shows the (i think) correct value
@&@/etc/machine.secret@&@
Even after ucr commit /opt/open-xchange/etc/authplugin.properties the file /opt/open-xchange/etc/authplugin.properties would still show the old value and therefore a login will not work until i set that new machine.secret pw manually?
Thanks
Sascha
You can resolve the machine.secret problem by executing
commit-ox-ucr-variables
followed by:
service open-xchange restart
to write the open-xchange config set by the UCR.
Alternativly you can trigger the password rotation via:
/usr/lib/univention-server/server_password_change.d/univention-ox postchange
This is also going to reload the ox service.
This can be found in our knowledge base article 13747
Hi Dirk,
good to hear, thanks a lot for your explanations.
Best
Sascha