Dear Ralph and Eli,
Thank you.
As Ralph suspected, there are quite many files on my system that had
wrong permissions or GID's.
Is there a way to automatically correct all the permissions and GID's?
Yours sincerely,
Xianwen
On 08/09/2019 11.28, Eli Schwartz via arch-general wrote:
On 9/8/19 5:20 AM, Ralph Corderoy wrote:
Dear Xianwen,
After searching on-line, it seemed that similar problems were reported
by other users of systemd. The fix is to set owner of / as root.root.
I tried the solution and it worked!
I'm glad you fixed it. / not being root:root is strange. You may wish
to
sudo -i pacman -Qqkk
to check for other odd permissions, etc., in case they too cause
problems later. Note, it seems normal for some packages to cause
grumbles from the above command. If a package is listed, I then do
sudo -i pacman -Qkk atop
to see more detail of the problem. Though unfortunately not enough
detail, i.e.
warning: atop: /var/log/atop/dummy_after (Permissions mismatch)
doesn't tell me what they should be. One has to grovel around in the
mtree file for that.
$ zcat /var/lib/pacman/local/atop-*/mtree |
> grep '^./var/log/atop/dummy_after ' |
> fmt
./var/log/atop/dummy_after time=1549485614.0
size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e
sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
$
This entry doesn't have a ‘mode=...’ stating the desired permissions.
mtree(5) doesn't say so, but I think it defaults to 0644 for files based
on the other mode-less entries in that mtree file that don't cause
pacman to complain.
Not every error means the file on disk must be changed, perhaps it's a
packaging problem, but it can be a useful aid.
pacman -S pacutils && paccheck --file-properties
