7

Possible Duplicate:
Wrongly set chmod / 777. Problems?

I am using Ubuntu for development purposes.

As I work on the database side, there are a lot of things which require file permissions in order to access the data directory or some other according to the requirement.

Every time I get an errors like:

[ERROR] path/to/directory/ permission denied

To avoid it I have to log in as root root from the terminal and give access to that directory with:

chmod -R 644 /path/to/directory

To avoid this problem completely, I have given full access privileges with the following command:

chmod -R 777 /

Now my system has some problems.

I am not able to log in as a root neither from OS accounts nor from the terminal. And if I restart the system I am not sure it will boot smoothly.

I think some of the files which should not be given the full access are given the full access and I don't know what those file are.

Can any one help me out?

2
  • 1
    In the future if you find permissions a hassle, just log in as root and work that way. Although people are often cautioned against this, what you just did is far worse in all respects (and would be even if the system still worked). If you don't want or need to do everything that way, just login or su from a shell when you do and run whatever from there. Not to encourage the practice too much, but I have been working primarily as root -- including in a professional setting -- for more than a decade and never even once shot myself in the foot because of it.
    – goldilocks
    Jan 21, 2013 at 13:39
  • 1
    "I insist on breaking my system, please help unbreak it". Better learn how to find out why it complains about permissions, instead of changing them willy-nilly with fingers crossed that this time it will work...
    – vonbrand
    Jan 22, 2013 at 20:26

3 Answers 3

Reset to default
8 
chmod -R 777 /

If you ever find yourself thinking of recursively applying mode 777 to any directory, please stop and take a moment to make absolutely sure that's what you want to do. 777 is shorthand for:

  • permit read, write and execute for the file's owner
  • permit read, write and execute for members of the file's group
  • permit read, write and execute for everyone on the system

(for simplicity's sake, I'll ignore the issue of setuid, setgid and sticky bits)

This is almost always not what you want.

Recursively applying this to the root (/) of the filesystem will set these permission on every file and directory on your machine . This is definitely Not What You Want.

In terms of recovering from this... purely hypothetically, if

  • Your Ubuntu box is still running sshd, and you can log into ssh as root

And you have another machine that

  • Can connect to your development machine over ssh
  • Has a filesystem that is very, very similar to your development machine (say, a clean installation of the same version of Ubuntu, and your DBMS of choice)

the following commands will copy that machine's file permissions onto your development box:

sudo find / -print0 | \
xargs -0 stat -c "chmod %a '%n'; chown -h %U:%G '%n';" | \
ssh user@your-development-machine

This will take some time to run.

This has a good chance of fixing a large number of the 777'd permissions on your Ubuntu box. However, even in the best case you should expect that you will encounter more permissions-related errors that you will need to fix manually.

The other option, and the one I would recommend, would be to start over completely. Backup your data, reinstall Ubuntu, your DBMS and any other software required on your development box.

2

If you no longer have root access you are out of luck, Reinstalling is your best bet.

There are files with fancy permissions like 4755 like the command su and sudo, and without that they won't run.

2

Giving the whole world read, write and execute access to your filesystem is usually a very bad idea. On the one side everyone with access to your computer can do basically anything with the system. And furthermore there are several system daemons like ssh which check the permissions of directories and files. If they are not correct, those daemons often fail to start.

The best solution for your current situation would be to restore it from a backup. So you get easily all files with the correct permissions back.

If you don't have a backup, the next practical solution would be to reinstall the system. So first you make a backup of your files, save the installed software (dpkg --get-selection > installed-software.txt), then install a new system and also install the software which you used (apt-get update && dpkg --set-selection < installed-software.txt && apt-get -u dselect-upgrade). Now you have a fresh system and you can update your config files.

Another solution would be to write a script. This script should walk through your filesystem recursively and compare the permission of each file and directory with some other system. It can change the permissions according to the other system. You maybe need to change some values, but this script could do the main work for you. This solution will also work, if you have physical access to your computer. Just boot it from a Live-CD or USB stick and mount the file system. Or you can also remove your harddrive and mount it at another computer.

However from my perspective the fastest way to get a working system back would be backing it up and reinstalling it.

2
  • thanks for your solution..... actually in the third solution without log in as root or sudo account shall we change the permissions?
    – vidyadhar
    Jan 21, 2013 at 11:38
  • @vidyadhar You probably want to work from a live CD or other separate system and mount the damaged one if you are going to try and repair it; in this case you will have root access if you want. To verify the results, you can use chroot.
    – goldilocks
    Jan 21, 2013 at 13:43

Not the answer you're looking for? Browse other questions tagged .