5

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.

photograph of console during boot

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.

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117
Goodies
  • 151
  • 1
  • 4
  • 3
    From a chroot, reinstall all of the applications listed in `/var/lib`. – jasonwryan Jan 11 '18 at 20:02
  • (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' Aug 23 '20 at 21:54
  • (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.* – G-Man Says 'Reinstate Monica' Aug 23 '20 at 21:54

4 Answers4

1

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 )...

francois P
  • 1,219
  • 11
  • 27
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.

jdwolf
  • 4,887
  • 1
  • 13
  • 28
0

Fixing this manually is not going to be trivial - you can guess at the possible ownership of directories under /var/lib based on entries in /etc/passwd but it's going to hit and miss. What happens if some files under an application directory are owned by the application and others by root (or vice versa)? You're going to be troubleshooting this for ages...

I'd suggest reinstalling all packages on your system. There are various ways to do this, for example:

# pacman -S $(pacman -Qeq) --noconfirm

I'd suggest you take a backup of your system before doing this though.

mjturner
  • 7,082
  • 1
  • 26
  • 32
0

restore from your backup next to the live-structure and set ownership same as it is on restored structure. - you could restore empty files/dirs, if your BUR system allows.

Klaus
  • 1