You are not logged in.
Pages: 1
I ran chmod -R 750 /root because my root folder was set to 700 and I got a warning when installing the filesystem package that was updated today.
warning: directory permissions differ on /root/
filesystem: 700 package: 750
This completely broke things. Immediately I couldn't sudo or open programs like the terminal. When I rebooted, startup failed because systemd-timersyncd.service didn't have permissions to its binary in /usr/*
I got the system to boot by doing chmod -R 755 on /root, going back to 700 didn't fix it.
Now I'm still in a busted state, sudo doesn't work due to this error:
❯ sudo su
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
I suspect that the recursive flag -R may have caused this. I'd appreciate some guidance on how to revert back to normal without doing a clean install.
Offline
So none of this adds up. There is nothing you could do to /root/ that would cause any of these problems (except for the warning from the filesystem package, which is just a warning).
I gather you had a stray space (e.g., `chmod -R 750 / root`), you have some symlink to / under /root/, or there is some completely unrelated cause of the other problems.
There is no way to know what would be needed to "revert back to normal" without having some idea what happened and / or what the actual damage is. Because again, there is absolutely nothing that you could do to /root/ that would cause any of these errors.
Please post a link to the complete output of `pacman -Qkk`.
If you can log into a tty as root, you could / should reinstall all packages:
pacman -Qnq | pacman -S -
Last edited by Trilby (2024-04-07 20:49:52)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Here is the output of `pacman -Qkk` https://gist.github.com/jfernandez/771d … 3c67137801
I'm also stumped by why changing permissions of /root would cause all of this. There are no symlinks in /root, just some random dotfiles. I had to change the permissions of /root to 755 to at least get the system to boot to Gnome, so it does indicate that somehow the /root permissions were causing the permission denied error for the systemd service.
Offline
No, that really doesn't add up. Have you been running gnome as the root user? (this relates to a question I didn't ask before but thought about: why do you care about the /root/ folder so much?) If you are running gnome as root, there's no telling the extent of damage that could have been done to your system - and purely for security reasons, I'd advise a clean install.
But if that's not the case, then it seems the problems noted in the -Qkk output are not too extensive. Most of the following packages are probably fine, but a couple are certainly damaged, so re-installing all of these should do:
pacman -S amd-ucode audit dbus filesystem fwupd gdm libutempter libvirt linux-headers openssh passim shadow sudo systemd tlp
Last edited by Trilby (2024-04-07 21:29:30)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I'm also stumped by why changing permissions of /root would cause all of this.
It wouldn't. Check your shell history, I'd bet Trilby is right and you had an extra space in the command.
Offline
I found it in my shell history, I don't see an extra space:
3525 sudo pacman -Syu
3526 sudo pacman -Syu filesystem
3527 for pkg in /var/cache/pacman/pkg/filesystem-*; do bsdtar tvf "$pkg" root; done\n
3528 sudo chmod 750 -R /root
3529 sudo pacman -Syu filesystem
3530 sudo
3531 sudo pacman -Syu
I restarted my laptop after that. Before that I installed https://aur.archlinux.org/packages/octopi and played a bit with it. I did try to use their cache clearing feature.
I re-installed all packages and things seem fine. I'm not using root for Gnome, I was just being OCD about the warning from the filesystem install.
Last edited by jrfernandez (2024-04-07 21:52:35)
Offline
Pages: 1