Server Fault is a question and answer site for system and network administrators. 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'm having some trouble with file permissions on an Ubuntu server. I'm using WinSCP to move files to the server. The server will work fine, and then after a while it appears that I no longer have permission to delete a file.

I'm connecting to the server using an account called svadmin, and the root directory of the Apache server is /var/www. Each website has it's own directory under this - i.e.


This is the output from the ls command...

cd /var/www
ls -al
drwxr-sr-x   4  svadmin  svadmin  4096 2009-06-12 14:45 .
drwxr-xr-x  15  root     root     4096 2009-05-05 15:47 ..
drwxr-sr-x   4  svadmin  svadmin  4096 2009-06-12 15:15  site1
drwxr-sr-x   4  svadmin  svadmin  4096 2009-06-12 15:15  site2

My understanding is that this mean the directory owner has read/write/execute? When I connect to the server using the svadmin account, shouldn't I be able to overwrite or delete files in /var/www/site1 or /var/www/site2?

I'm not very familiar with linux file/directory permissions, so have been struggling to work out what I should be doing. Any help would be greatly appreciated!

More info: (thanks for the quick replies!)

Output of ls -al for /var/www/site1

drwxr-sr-x 4 svadmin svadmin 4096 2009-06-12 15:15 .
drwxr-sr-x 4 svadmin svadmin 4096 2009-06-12 14:45 ..
-rw-r--r-- 1 svadmin svadmin 157  2009-05-12 13:23 error.php
-rw-r--r-- 1 svadmin svadmin 158  2009-05-12 13:23 .htaccess
-rw-r--r-- 1 svadmin svadmin 142  2009-05-12 13:23 index.php
drwxr-sr-x 2 svadmin svadmin 4096 2009-05-12 18:40 libraries

Error message When I try and delete the file:

rm admin.php
rm: cannot remove 'admin.php' : Read-only file system

Even more info Just to add some possibly relevant information... everything was working until yesterday afternoon. At that point a coworker took out the SAN that the virtual machine file was on, and the web server had a less than graceful shutdown.

share|improve this question
Can you post the output of ls -lA /var/www/site1/? – theotherreceive Jul 16 '09 at 18:38
Could you also post any error you get when trying to delete a file? – thepocketwade Jul 16 '09 at 18:46
Thanks for the quick replies - I added more info... – Matt Jul 16 '09 at 19:47
I presume the above error is from winscp? Can you try to remove the files with rm (like, over ssh), and see if that generates an error. – theotherreceive Jul 16 '09 at 20:08
I changed the error to what it is if I used rm - thanks again! – Matt Jul 16 '09 at 20:58
up vote 3 down vote accepted

This isn't a permissions problem. The two clues are:

  • rm: cannot remove 'admin.php' : Read-only file system
  • everything was working until yesterday afternoon. At that point a coworker took out the SAN that the virtual machine file was on, and the web server had a less than graceful shutdown.

Somehow the filesystem containing /var/www dropped to "read only" probably when the SAN went away. The output of the mount command should identify this filesystem with a (ro) flag at the end.

The fix is to figure out why it happened, make sure it's corrected, and remount the filesystem rw with this command:

mount -oremount,rw $filesystem

share|improve this answer
It sounds like /var/www is remotely mounted (on the aforementioned SAN), in which case, the debugging may need to happen on the fileserver. That would mean that the server in question shows the filesystem mounted read/write, but the fileserver has the filesystem read-only. – Chad Huneycutt Jul 16 '09 at 22:08
Thanks - the problem was related to the SAN issue, and mounting the drive seemed to solve the problem. Thanks again! – Matt Jul 27 '09 at 21:24
Glad to hear it worked. – Insyte Jul 27 '09 at 23:00
Or is fixed, rather. – Insyte Jul 27 '09 at 23:01

If you have rwx on a directory, that means you can edit the directory file, which amounts to removing and adding files. Editing files is a function of their individual permissions. What does an ls -l of one of the subdirectories look like?

share|improve this answer
Thanks - I added the output... – Matt Jul 16 '09 at 19:48

Your problem is the sticky bit. Notice that the perms there aren't drwxr-xr-x, they are drwxr-sr-x. Wikipedia says:

The most common use of the sticky bit today is on directories, where, when set, items inside the directory can be renamed or deleted only by the item's owner, the directory's owner, or the superuser; without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986 and today it is found in most modern Unix systems.

So, files are only writable and deletable by the group that put them there in the first place.

share|improve this answer
The "sticky" bit is not set, rather it's the "setgid" bit. The setgid bit forces files dropped into the directory to be owned by the same group as the directory. The sticky bit is indicated by a 't' in the last position of the perms, like so: <pre> $ mkdir test $ chmod a+t test $ ls -ld test drwxr-xr-t 2 insyte staff 6 2009-07-16 16:52 test </pre> – Insyte Jul 16 '09 at 22:02

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.