Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I ran chmod 777 recursively on /var/ and could no longer connect via SSH. I read that chmod 600 would fix it. I was able to connect after doing it but this was a bad idea.

Is there anyway I can find the default modes for the folders in /var/ or how to fix this?

Running on Debian-Squeeze.

share|improve this question
The default is 755 on my Squeezes. – paradroid May 25 '12 at 2:05
@paradroid Thank you – Kevin Duke May 25 '12 at 2:32
up vote 3 down vote accepted

This is a very common error for people coming from an OS that lack the permission concept. Many

sudo chmod -R 777 /

and such have been issued with perhaps good intentions, but it is also more or less the one user error that could make me recommend "just reinstall" for a *nix system.

If you just chmod -R 755, then you will among other things give read and execution permission to every file for anyone. If one just removes execution for every file (directories need it to be browsable), then one will remove the execution bit for some files that were supposed to be executable, and so on.

In this case it is perhaps not as severe as -R /, but in e.g. /var/log there are many files that are not supposed to have read permissions for anyone. A small excerpt:

-rw-r--r-- alternatives.log
drwxr-x--- apache2
drwxr-xr-x apt
-rw-r--r-- aptitude
-rw-r----- auth.log
-rw-r----- boot
-rw-rw---- btmp
drwxr-xr-x ConsoleKit
drwxr-xr-x cups
-rw-r----- daemon.log
drwxr-xr-x dbconfig-common
-rw-r----- debug
-rw-r----- dmesg
-rw-r--r-- dpkg.log
-rw-r--r-- duplicity-backup.0
drwxr-s--- exim4
-rw-r----- fail2ban.log
-rw-r--r-- faillog
-rw-r--r-- fontconfig.log
drwxr-xr-x fsck
drwxr-xr-x hp
drwxr-xr-x installer
-rw-r----- kern.log
-rw-rw-r-- lastlog
-rw-r--r-- lpr.log
-rw-r--r-- mail.err
-rw-r--r-- mail.log
-rw-r--r-- mail.warn
-rw-r----- messages
drwxr-x--- mrtg
drwxr-s--- mysql
-rw-r----- mysql.err
-rw-r----- mysql.log
drwxr-sr-x news
-rw-r--r-- popularity-contest
-rw-r--r-- pycentral.log
-rw-r--r-- rssdler.log
drwxr-xr-x samba
-rw-r----- shorewall-init.log
-rw-r----- syslog
drwxr-xr-x unattended-upgrades
-rw-r----- user.log
-rw-rw-r-- wtmp
-rw-r--r-- Xorg.0.log

This is not trivial to restore. And that was just one directory.

All in all: even if you did make SSH work again, you have had some not trivially repairable permission information loss. If it concerns a strictly personal server, the consequences are probably not that dire, but the permissions are set as restrictive as possible for a reason. In e.g. the log files I mentioned above, sensitive information may be stored, and now it is enough for an exploit with gives regular user rights to find this out and gain even more information for root permission attacks.

I last saw someone give the "Do chmod -R 777!!!" tip yesterday on a local forum. Don't trust the internet! :-)

share|improve this answer
Nice post, thank you. Question: why would chmod 777 break anything if we are just giving permissions to everybody? Do some things not work if other things have permissions? – Kevin Duke May 25 '12 at 7:29
@KevinDuke: It's first and foremost a permission problem. As you noticed, the SSH server won't even start if the permissions are too loose. I found… on the topic; read the two top ranked answers (and forcefully ignore the accepted one, that is rightfully at -6). I believe they express the seriousness of the situation very well. – Daniel Andersson May 25 '12 at 7:34
Addition to the above comment: I noted that the accepted answer to the linked question that was at −6 is now deleted altogether. – Daniel Andersson Mar 11 '14 at 6:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.