0

I've extracted a tar file with sudo to / which contained the following file structure:

Since then I can't do anything on my server anymore, each command is either permission denied or command not found. Also most of the programs, like Apache or SSH, don't work anymore, although the system is still writing to log files and the virtual machines are still running.

At first I thought I've overwritten the whole /usr directory, but actually that's not the case. I've accessed my server via a rescue system and all the files are still there. The permissions seem to be okay too, they all belong to root with 0755 (see second screenshot). The new files have just been extracted into the existing folders, so I don't see how this could have done any harm (I've now deleted them).

Unfortunately I don't have a backup of /usr.

I really don't have an idea what to do now, so it would be great if you could help me. Please let me know if you need any more information.

Improve this question
10
  • 5
    I think this falls into the category of "don't do that then". "I really don't have an idea what to do now". A reinstallation is probably your best bet. The alternative is to spend a lot of time messing with your system. You'll probably learn quite a lot about Unix-like systems and Debian in particular, but that may not be what you want to be doing... Oh, and avoid screenshots of text. Just paste in the text. Commented Feb 9, 2015 at 19:04
  • 1
    @FaheemMitha I'd really prefer solving this without a reinstallation, just need a hint where to start. Commented Feb 9, 2015 at 19:13
  • Well, a simple way would be to look at all those files you have extracted, and then compare those to the permissions of all those files on a non-broken system. If that doesn't work, you'll have to extend things to a larger set of files. There might be better approaches. Another approach is to look at the programs that are not working and try to determine if their permissions looks reasonable. Bear in mind that if the directory permissions as screwed up, it may affect the permissions of the files in them. Commented Feb 9, 2015 at 19:30
  • The old files haven't changed as far as I can see. There have been extracted some new ones, but I've already deleted them. The second screenshot I've attached shows that the permissions are intact. Could this have something to do with the file system in general or with mounting? Commented Feb 9, 2015 at 19:35
  • The permissions might have changed. Are you sure they haven't? I'm talking specifically about the directory permissions, not so much the file permissions. Commented Feb 9, 2015 at 19:38

1 Answer 1

Reset to default
0

Check this output on your machine. Two things to note:

  1. The sticky bit should be set on /usr/local and everything below it. From the listing in your question, this does not appear to be the case.
  2. You need to check that the group is staff for everything in /usr/local and below.

2 is unlikely to be your problem. 1 might well be.

root@orwell:/usr/local# ls -lah
total 52K
drwxrwsr-x  11 root staff 4.0K May 26  2014 .
drwxr-xr-x  12 root root  4.0K May 30  2014 ..
drwxrwsr-x   2 root staff 4.0K Aug  4  2014 bin
drwxr-xr-x   3 root root  4.0K May 26  2014 Brother
drwxrwsr-x   2 root staff 4.0K Jul 31  2013 etc
drwxrwsr-x   2 root staff 4.0K Jul 31  2013 games
drwxrwsr-x   2 root staff 4.0K Jul 31  2013 include
drwxrwsr-x   8 root staff 4.0K Dec  5  2013 lib
lrwxrwxrwx   1 root staff    9 Jul 31  2013 man -> share/man
drwxrwsr-x   2 root staff 4.0K Jul 31  2013 sbin
drwxrwsr-x  11 root staff 4.0K Mar 10  2014 share
drwxrwsr-x 265 root staff  12K Jan 31 07:08 src
Improve this answer
5
  • Thank you, I'm pretty sure this was part of the problem. Now I only have to restore the permissions of /. Commented Feb 9, 2015 at 20:27
  • That is very strange... ubuntu doesn't do this and I don't see how it could cause a problem. The intent seems to be to allow the group "staff" to install programs to /usr/local directly rather than having to su(do). Commented Feb 9, 2015 at 21:07
  • @psusi Ubuntu doesn't do what? And what shouldn't cause a problem? Commented Feb 9, 2015 at 21:36
  • Set the sticky bit and group ownership to staff on /usr/local -- it's just root.root with no sticky. Commented Feb 10, 2015 at 13:39
  • @psusi that is indeed strange. Ubuntu usually follows whatever Debian does, at least in the base system. Commented Feb 10, 2015 at 15:10

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.