Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

/var/www/site1
/var/www/site2

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
show 1 more comment

4 Answers 4

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
add comment

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
add comment

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
add comment

CHMOD

Section: User Commands (1)

NAME

chmod - change file mode bits

SYNOPSIS

chmod [OPTION]... MODE[,MODE]... FILE... chmod [OPTION]... OCTAL-MODE FILE... chmod [OPTION]... --reference=RFILE FILE...

DESCRIPTION

This manual page documents the GNU version of chmod. chmod changes the file mode bits of each given file according to mode, which can be either a symbolic representation of changes to make, or an octal number representing the bit pattern for the new mode bits.

The format of a symbolic mode is [ugoa. . .][[+-=][perms. . .]. . .], where perms is either zero or more letters from the set rwxXst, or a single letter from the set ugo. Multiple symbolic modes can be given, separated by commas.

A combination of the letters ugoa controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if a were given, but bits that are set in the umask are not affected.

The operator + causes the selected file mode bits to be added to the existing file mode bits of each file; - causes them to be removed; and = causes them to be added and causes unmentioned bits to be removed except that a directory's unmentioned set user and group ID bits are not affected.

The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). Instead of one or more of these letters, you can specify exactly one of the letters ugo: the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file's group (g), and the permissions granted to users that are in neither of the two preceding categories (o).

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros. The first digit selects the set user ID (4) and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file's group, with the same values; and the fourth for other users not in the file's group, with the same values.

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals. SETUID AND SETGID BITS chmod clears the set-group-ID bit of a regular file if the file's group ID does not match the user's effective group ID or one of the user's supplementary group IDs, unless the user has appropriate privileges. Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

chmod preserves a directory's set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode. Section: User Commands (1) NAME chmod - change file mode bits SYNOPSIS chmod [OPTION]... MODE[,MODE]... FILE... chmod [OPTION]... OCTAL-MODE FILE... chmod [OPTION]... --reference=RFILE FILE... DESCRIPTION This manual page documents the GNU version of chmod. chmod changes the file mode bits of each given file according to mode, which can be either a symbolic representation of changes to make, or an octal number representing the bit pattern for the new mode bits.

The format of a symbolic mode is [ugoa. . .][[+-=][perms. . .]. . .], where perms is either zero or more letters from the set rwxXst, or a single letter from the set ugo. Multiple symbolic modes can be given, separated by commas.

A combination of the letters ugoa controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if a were given, but bits that are set in the umask are not affected.

The operator + causes the selected file mode bits to be added to the existing file mode bits of each file; - causes them to be removed; and = causes them to be added and causes unmentioned bits to be removed except that a directory's unmentioned set user and group ID bits are not affected.

The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). Instead of one or more of these letters, you can specify exactly one of the letters ugo: the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file's group (g), and the permissions granted to users that are in neither of the two preceding categories (o).

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros. The first digit selects the set user ID (4) and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file's group, with the same values; and the fourth for other users not in the file's group, with the same values.

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals. SETUID AND SETGID BITS chmod clears the set-group-ID bit of a regular file if the file's group ID does not match the user's effective group ID or one of the user's supplementary group IDs, unless the user has appropriate privileges. Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

chmod preserves a directory's set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode.

share|improve this answer
    
This seems a little harsh... –  Anthony Lewis Jul 16 '09 at 19:40
    
I think is a bad idea to cut&paste a man page. A link to a chmod man page gives better answer. –  FerranB Jul 16 '09 at 19:40
    
Thanks for the information, I really appreciate it. I'd come across several articles similar to this while searching before I asked on here. I understand the structure of the formatted letters, and the other concepts. That's just it! My subdirectory has -rw and the owner is the account I am using. Shouldn't I have read and WRITE access? I apologise if this seems really easy, and know that people get sick of answering similar questions relating to file permissions. I also suspect that I'm not the only new person to linux wondering why this permission system is so frustrating to learn! –  Matt Jul 16 '09 at 19:57
    
The account owns all the files in question - chmod isn't really relevant here. –  theotherreceive Jul 16 '09 at 20:06
add comment

Your Answer

 
discard

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.