Checked an old log and see that chrony was updated from version 3.3 to 3.4
It is a pity that the error is not giving hints on what is wrong, but the good thing of open source is that you can look into the sources and there I found that the permissions are and-ed with 0770 and if that gives a non-zero result you get this error.
Had a look and my system and saw, the permission were indeed not right and corrected them:
> ls -ld /var/run/chrony
drwxr-xr-x 2 chrony chrony 60 Nov 3 17:28 /var/run/chrony
> sudo chmod o-rx /var/run/chrony
[sudo] password for root:
> ls -ld /var/run/chrony
drwxr-x--- 2 chrony chrony 60 Nov 3 17:28 /var/run/chrony
Did reboot but still the error, checked again /var/run/chrony and saw the old permissions were back and the time-stamp updated to 2 minutes after the last boot.
What is going on?
Searching a bit further I found /run and /var/run are created run-time so seeing the file with the updated timestamp makes sense.
Next question is which process creates /var/run/chrony, in the sources I see chrony will make the directory if it does not exist but I would expect it then to have the right permissions.
Likely systemd does create the directory but with the wrong permissions. Checked /usr/lib/tmpfiles.d but some /var/run directories are specified there but not /var/run/chrony
In /usr/lib/systemd/system/chronyd.service there is:
I am seeing the same error messages for “chronyd”. It does not appear to cause problems. That is to say, “chronyd” is still running and apparently keeping the time synchronized.
From the error message, it looks as if “chronyd” opens a control socket, but it is not doing that when the permissions are wrong. So you lose the ability to use the control socket, but it otherwise works.
Maybe a bug report is in order. Let the maintainers of “chronyd” for openSUSE look into a solution.
I do not know if they are related, but I had a similar problem with sshfs after recent updates, wrong permissions. Running the command I gave above fixed the problem.