I accidently ran
sudo chmod 755 -R /
instead of
sudo chmod 755 -R ./
I stopped it after few seconds, but now there is some problems such as
sudo: must be setuid root
How can I revert permissions back?
I accidently ran
sudo chmod 755 -R /
instead of
sudo chmod 755 -R ./
I stopped it after few seconds, but now there is some problems such as
sudo: must be setuid root
How can I revert permissions back?
In short: you can't, reinstall your system.
I mean, Posix permissions are used and relied on heavily; there's a multitude of places in the filesystem where wrong permissions would break the OS (SUID flags) or even worse, make it exposed security-wise (
/etc/ssh/ssh_host_rsa_key
) while it appears to be working OK.Hence, such a recovery is hard to do properly. Miss one thing — and you screw it up. You already screwed up your
sudo chmod
command (if that's your friend rather than you, she might as well learn some Linux lesson, too) — and that's a very simple of a command. Proper recovery would demand way more commands and way more vigilance. Even if you use someone's script.So trust me, just reinstall. It's a safe bet and guaranteed to keep you out of trouble.
Finally, some tips relevant here.
First: reinstalls will be less painful if you setup your
/home
on a separate partition next time. Actually, they will be a breeze.Second: consider doing crazy Linux science in a virtual machine like the VirtualBox, and do your snapshots.
Third:
chmod -R .
works. A dot by itself.
is valid directory name. There's no real need to append that slash. You could've avoided the catastrophic risk of skipping the dot entrirely;mere
chmod: missing operand after ‘755’
VS a ruined system.I wrote and have been using for several years a couple of Ruby scripts to
rsync
permissions and ownership. Scriptget-filesystem-acl
collects all the information by recursively traversing all the files and puts it all into the file.acl
. Script.acl-restore
will read.acl
and apply all thechown
's andchmod
's.You can run
get-filesystem-acl
on a similar Ubuntu installation and then copy over the.acl
file to your chmod-damaged box, put.acl
and.acl-restore
in /, and run.acl-restore
.You will need to have root so fix your
sudo
as Marco Ceppi suggested.I can generate and give you the
.acl
file for my Ubuntu.get-filesystem-acl
.acl-restore
In long: you can. You'll need to mount the the file system from the a Live CD and begin reverting the permissions in the appropriate places. At a minimum to get sudo back you'll want to run
sudo chmod u+s /usr/bin/sudo
while in the LiveCD session - that will fix the must be setuid root.However, it would likely be easier to simply reinstall the system.
I would try to reinstall all packages with
apt-get install --reinstall
, possibly using the output ofdpkg --get-selections | grep install
to get a list of them.Alright, I haven't tested this (so use at your own risk), but it still might work. I Will test this in a virtual machine when I get the chance to:
First, in a still working system, I did the following to get all file permissions in a list, skipping the
/home/
directory:This will print the permissions and file name for each file or directory on the system, followed by a
\0
character (this is needed later on to deal with weird file names such as those containing newlines).Then, on a system where the file permissions have been compromised:
This will read each line of
fileper.log
, saving the permissions as$perm
and the file name as$file
and then will set the file (or directory's) permissions to whatever was listed in thefileper.log
A few things to note here:
/tmp/fileper.log
, you might be listing custom settings, and proc, etc.What I would suggest is boot up a LiveCD with the Linux version you have on your disk, run the command, modify the path to where you have the local disk mounted, and run the second command!
I have tested that when booted from an Ubuntu CD/USB, I can choose not to format disk, meaning it will replace everything in the
/
directory, BUT skip the/home/
directory. Meaning your users will have the configuration of apps/DATA(Music,Video,Documents) still intact. And by replacing the system files, thechmod
is set to there proper number.You can try restoring permissions with
apt-get
.If you can not run these commands with sudo you may need to boot to recovery mode and run them as root.
For booting to recovery mode see https://wiki.ubuntu.com/RecoveryMode.
From http://hyperlogos.org/page/Restoring-Permissions-Debian-System
Note: This was originally posted on the Ubuntu Forums but I can not find the original post.
Try, in order,
If that fails:
And finally, as a last resort,
Using apt-get
Here's the relevant snip, EDITED FOR CORRECTNESS and reformatted:
(I know I shouldn't comment in an answer, but not enough reputation to comment.)
blade19899's answer worked for me except for symlinks. E.g. it applied 755 to /bin/bash, but then applied 777 to the symlink /bin/rbash, effectively 777-ing /bin/bash.
As I already had the fileper.log file, I just modified the destination-end command:
All answers here focus (predictably) on restoring the system to a working state. But no answer focuses on how to better prevent a similar accident in the future.
To completely prevent accidents like this in the future, add the following to your
~/.bashrc
(or~/.bash_aliases
) file:Also, make sure the same contents are inside the
~/.bashrc
(or~/.bash_aliases
) file of theroot
user as well (else it doesn't matter!).In this way, you CAN NOT use these commands (even as
root
) recursively on the root filesystem.There is a closed question (with a great answer) as duplicate of this one from:
As such I will give Terdon the credit but here is my own answer based his.
During development of a new script, the variable
$TMP_DIRECTORY/
had unexpected result of/
. This was followed bychmod 700
andchown -R $UDO_USER
pointing to$TMP_DIRECTORY
which was really/
.System slowly crashed and burned. After that it would not reboot. Everyone screams "YOU MUST REINSTALL" but that means loosing years of work. This script is a variation of Terdon's answer:
When running the script with
$ sudo reset-owner /mnt/old/var /var | grep "No reference"
the tail end says this:As daunting as it seems it only took an hour to work it all out. By the time I was done I was left with this:
For packages, the easiest, fastest, and more stable option that I know of is this Aptitude command below.
In summary, this command automatically restore a package permissions to their default. Including both all its default folder(s) & file(s). The end result is as if the package was freshly installed for the first time with its default permission. While at the same time keeping any already existing configuration file(s).
Three Steps
Step 1
Using Terminal/Console, connect into the appropriate Linux user account. This is important because in both steps 2 & 3 below all commands will be executed as this user.
Step 2
If not already done, using Terminal execute this command to install Sudo
Note: For those not familiar with Sudo, allow a Linux user(s) limited super user privileges
If not already done, using Terminal execute this command to install Aptitude
Note: For those not familiar with Aptitude, it is a package manager. Which is similar to Apt. Aptitude has more functionality than Apt. Aptitude includes both an interactive UI and a text-only interface/CLI. In comparison, Apt lacks an interactive UI. Aptitude is a high-level package manager while Apt is lower-level package manager.
Step 3
Choose one of the four options below. Which will reset the package permissions to their default. And keep the package(s) configuration:
Option 1: ONE package. WITHOUT Backport.
Format:
sudo aptitude reinstall <PACKAGE NAME>
Example:
sudo aptitude reinstall jami
Option 2: ALL packages. WITHOUT Backport.
sudo aptitude reinstall '~i'
Note
Option 3: ONE package. WITH Backport.
Format:
sudo aptitude -t <CODE NAME DEBIAN>-backports reinstall <PACKAGE NAME>
Example:
sudo aptitude -t buster-backports reinstall jami
Note
Option 4: ALL packages. WITH Backport.
Format:
sudo aptitude -t <CODE NAME DEBIAN>-backports reinstall '~i'
Example:
sudo aptitude -t buster-backports reinstall '~i'
Note
This option above is for Debian 10 Buster. If you use Ubuntu, you would need to adapt this command. Related documentation at https://help.ubuntu.com/community/UbuntuBackports Note
This option above will both reinstall ALL already installed packages and reset their permissions to their default. Including your operating system (OS). Before executing this command, it is suggested to complete the appropriate actions. Such as, but not limited to, create a backup, check that you have enough available locale storage. Time needed for this command is similar to installing a new OS.
Notes about all four options above
Attribution
Thanks to this Debian wiki for those options above at https://wiki.debian.org/Permissions/ResetPackagePermissions