Messed up folder and file permissions - restore defaults for /run

[Schmu]

Hello everyone,

I never thought this happens to me so soon, but I messed up my system and many things like copy and paste from and to Firefox, starting apps, having sound and so stopped working when I changed permissions for subfolders and files recursive for the /var/lib/docker/overlay2/ folder after the security checker wazuh-agent complaint about world-write permissions on files owned by root.
I thought this was only docker related, I don’t use it any time soon and if something fails with docker in the future I could easily change the permissions again.

Turns out this folder contained many softlinks to important filesystem’s like /run (maybe more).

Next “great” thought: /run is a tmpfs so after a restart everything is probably back to normal, but now loading the sddm login screen and a few services don’t work anymore.

Anyway: can somebody tell me the best way to restore the default permissions under /run and maybe other filesystem’s which are important to Linux (not sure yet what else is affected).

I searched the Internet already and found that permissions of installed packages can be fixed by reinstalling them or maybe with a script after checking the packages’ file permissions:
paccheck --file-properties --quiet | grep permission

But this would not fix such problems in /run am I right?

I only have a few hours later when the child sleeps so I try to be maximum prepared and make some progress later. I hope someone can help me with steps I can follow.

Thanks a lot!

---

P.S.: What a shame threads are closed so quickly. I was just about to respond and then it was closed already. I just wanted to provide more details and say thank you.

Here is the text which I cannot send in any other way:

Thank you so much @Mirdarthos and @linux-aarhus ! You guys really helped me out.

With pacrepairfile I was able to repair all permissions.
I used
LANG=C pacman -Qkk 2>&1 | grep "Permissions mismatch" | grep -o 'warning: .*' | awk '{print $3}' > messed_up_files.txt
to get a list of files/ folders where the permissions no longer matched.

On the file list I ran:
cat messed_up_files_clean_list.txt | pacrepairfile --uid --gid --mode

I double checked under /var/lib/docker/overlay2 where softlinks are leading to noticed that a few links lead to /var as well and I cross checked, that the permissions were fine now as well. A few files/ folders still seemed odd (could have been right though), so just to be sure I again prepared a list of files/ folders (this time manually) and sent it to pacrepairfile. It did something, so maybe that was also helping.

After a restart everything was fine again and I’m writing this message from my Manjaro machine

Thank you so much and have a great evening and a great start for the week.

[Mirdarthos]

Hi @Schmu,

While I’ve never used this, I believe wat you’re looking for is pacrepairfile:

$ pacrepairfile -h
pacrepairfile: invalid option -- 'h'
pacrepairfile - reset properties on alpm-managed files
usage:  pacrepairfile [options] <file>...
pacrepairfile (--help|--version)

--config=<path>    set an alternate configuration file
--dbpath=<path>    set an alternate database location
--root=<path>      set an alternate installation root
--sysroot=<path>   set an alternate system root
--quiet            do not display progress information
--help             display this help information
--version          display version information

--package=<name>   search package <name> for file properties
--uid              set file owner id
--gid              set file group id
--mode             set file permissions
--mtime            set file modification time

pacrepairfile is part of the pacutils package, if you don’t have it installed.

Usage is probably something like

sudo pacrepairfile

But that’s just a guess…

[Schmu]

Interesting hint, thank you very much!
I’ll try:
sudo LANG=C pacman -Qkk | sudo pacrepairfile --uid --gid --mode

And this fixes /run as well, right? Does that filesystem store package files as well? I thought it only stores files required by Linux during runtime.

[linux-aarhus]

/run is volatile and usually recreated on boot - but that may just be an assumption of mine.

[Mirdarthos]

@Schmu

Does that filesystem store package files as well?

AFAK it has to be in the mtree. From https://man.archlinux.org/man/pacrepairfile.1:

Resets file properties for alpm-managed files based on MTREE data.

And, what @linux-aarhus said:

@linux-aarhus

/run is volatile and usually recreated on boot - but that may just be an assumption of mine.

Indeed:

$ mount | grep -i run
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
[...]

Based on Linux File Hierarchy Structure - GeeksforGeeks :

Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, following the FHS version 3.0.

Edit:

And according to Filesystem Hierarchy Standard - Wikipedia :

/run: Run-time variable data: Information about the running system since last boot, e.g., currently logged-in users and running daemons. Files under this directory must be either removed or truncated at the beginning of the boot process, but this is not necessary on systems that provide this directory as a temporary filesystem (tmpfs). |