Restore file ownership after running chown by accident

Question

I recently upgraded my PostgreSQL installation and intended to run the command:

sudo chown -R postgres:postgres /var/lib/postgres

Unfortunately, I accidentally forgot the “postgres” part at the end because of a miscalculated tab completion... I ended up running:

sudo chown -R postgres:postgres /var/lib

Needless to say, this has caused a slew of issues. For example, I’m not able to boot into my operating system.

---

Update:

I applied chown -R gdm:gdm /var/lib/gdm and am now able to log in successfully!  However, I don't know the extent to which this will cause problems.

---

I’m running Arch Linux with i3 as the window manager and GDM as the display manager. I would appreciate any help in getting the original ownership to the necessary directories in /var/lib. As of now, it permanently hangs on this part of the process, after

         Starting User Manager for UID 120...
[  OK  ] Started Session c1 of user gdm.
[  OK  ] Started User Manager for UID 120.

I am using LUKS and the filesystem is encrypted.

However, I am able to spawn a shell via grub by adding init=/bin/bash to the kernel line, of course, so this should be fairly easy to fix once I know the proper ownership requirements.

Currently in /var/lib:

• colord is owned by colord,
• gdm is owned by gdm,
• locate and mlocate are owned by root,
• redis is owned by redis,
• systemd is owned by root, and
• everything else is owned by postgres.

See photograph of ls -ho output for permissions and modification times.

One issue is that the /var/lib/gdm directory, which is owned by gdm, contains typical home-directory sub-directories (Desktop, Documents, Downloads, Music, Pictures, Public, Templates and Videos), all of which are owned by postgres.  See photograph of ls -ho output for permissions and modification times.

How can I fix the file ownership in /var/lib back to how it was before I ran

chown -R postgres:postgres /var/lib

?  Any aid would be greatly appreciated.

Solution 1

The /var file system hierarchy are for data created by applications and therefor package managers manage very little in /var. For the most part pacman -Qo is only going to return ownership for the top level directories in /var/lib as its structure is to have each application have one directory.

You first want set everything to root owner for a more sane default than postgres.

chown -R root:root /var/lib/

Reinstall packages that have owned files in /var/lib

pacman -Qo $(find /var/lib) 2>/dev/null

Now look at who owns each directory:

ls -la /var/lib

Everything in directories owned by root will be owned by root. Whereas directories not owned by root are actually application users home directories. With little exception then all the files contained in those directories are owned by the application user. So running chown -R gdm:gdm /var/lib/gdm works. But there are exceptions. For example on my system /var/lib/sddm/state.conf is owned by root.

Solution 2

You can get back with chown commands on directories with informations you know from usernames from /etc/passwords & their group from /etc/groups the rest will belong to root:root

but it is a little tricky until you can let a bug ... that will appears in many many many days.... due to a forgotten change....

I think postgres gdm are ok the rest may belong to root redis to redis ... i think tor also have it's dedicated user.

---

The easy way : reinstall all of it (after backup of your database & of course without formatting /home )...

Comments

[jasonwryan]

From a chroot, reinstall all of the applications listed in /var/lib.

[G-Man Says 'Reinstate Monica']

(1) I understand that it’s very hard to extract data from a system that you can’t log in to, and, even if you can log in, it can be hard to capture the boot screen, so sometimes photographs of the monitor are the best you can do.  (Although the boot screen messages are often accessible from log files.)  And, if you have only console-type access (i.e., no window system; as you get with init=/bin/bash), it can be very hard (if not impossible) to get traditional screen snapshots.  But (1a) Once you get shell access, try to run commands such as ls with output to a file,  … (Cont’d)

[G-Man Says 'Reinstate Monica']

(Cont’d) …  and then move that file to a fully functional system via a removable drive (e.g., a “thumb drive”) or the network, and (1b) If you must use photographs, please crop them, so they don’t include a lot of blank space.  (2) If you’re going to show us directory listings, use the -a option to ls, so we can see the . files.  (When troubleshooting, . and .. can be very important.)  (3) In general, but especially when group ownership is an issue, use ls -l rather than ls -o, so we can see the user and the group.

[jdwolf]

This would set all packages as explicitly installed.