3

I am using Debian. I tried to give a permissions to /opt/folder by using

chmod -R 0755 / filename

Unfortunately it changed the permissions of a lot of folders in the root filesystem. So it leads into a lot of problem.

Now I can't open any application (i.e) Terminal, Browser or even I get errors on restart.

How to open a Terminal? (starting and stopping)

How to resolve this whole problem?

Braiam
  • 35,991
Silviaa
  • 253
  • Never use recursive chmod on the root directory! Most unix commands that take a filename as a parameter can take more than one (otherwise filename wildcard substitution wouldn't work). In your example, you have (by mistake, I assume) a space between the leading slash / and filename. This means: first change the permissions recursively on the root directory and everything beneath it, and then on filename in the current directory. Probably not what you wanted. – MattBianco Aug 13 '14 at 08:43

2 Answers2

4

You've recursively changed permission on every file under root (/) and also filename. This is because you've a space between the two.

You a few options:

  1. Fix the permissions. This will involve trying to figure out the correct permission for every file under / - a very time consuming task. One possible way to do this would be to install another copy of the same distro with all (or as many as you can work out) packages as the original to use as a reference.
  2. A small variation on the above, if you're up to it: You could boot with a recovery disk and mount both the original (corrupted) and new install partitions/disk. From there, write a script that will recursively copy the permissions from the working to the new. See below for an example.
  3. Restore from a backup.
  4. If you don't have a backup, re-install.

As a starter, here's an untested script that should work:

  brkd=/mount/borked
  good=mount/fresh
  find $good -type f | xargs -I {} chmod --reference {} $brkd{}
garethTheRed
  • 33,957
1

You gave an unneeded space after the slash.

Your terminal problems will be fixed by a reboot. These permissions are long in a ramfs-based filesystem which will be reconstructed on every reboot. But warn: you system is currently probably unbootable, thus after a reboot you started probably on a rescue system.

If you don't have a backup, you need to know, which directories permission was erased. The best solution were to get into another linux, compare the permissions with well with welldirected ls commands, starting from the root, and then reset them on your system.

peterh
  • 9,731
  • I don't think a reboot will help. In fact, it can make big problems: the computer not booting. It is best trying to fix everything from current session and, once pretty sure, reboot. – fedorqui Aug 13 '14 at 11:23
  • 1
    @fedorqui 1: /dev is on a ramdisk and its device nodes (with their permissions) will be generated on boot. Thus these will be surely reseted. 2: yes, it is very surely that he will begin with a rescue system after a reboot. I extended now my answer to warn this for that. – peterh Aug 13 '14 at 11:37