Ever drove yourself nuts because you could not delete a file? Remove the file lead to an error:
% rm -f file rm: cannot remove `file': Permission denied
% rm -f file rm: file: Operation not permitted
Obviously, you checked that the permission are correct. They are here.
% whoami freek % ls -la file -rw-r--r-- 1 freek user 0 Apr 28 07:30 file
Here are a few tips for further checks.
Restrictive Parent Folder
Your first attempt would be to look for the permissions of the parent folder:
% ls -l file.txt; ls -ld . * dr-xr-xr-x 2 7432 user 4096 Feb 25 00:03 ./ -rw-r--r-- 1 7432 user 0 Apr 28 07:30 file.txt
In this case, the file could not be deleted due to a restrictive folder. Fix with chmod:
chmod u+w .
Disk is Locked
To view a list of mounted file systems, use mount without any arguments.
[On Linux] % mount /dev/sda1 on / type ext3 (rw,errors=remount-ro,usrquota,grpquota) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw) [On Mac OS X] % mount /dev/disk0s10 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol /dev/disk0s12 on /Applications (local, journaled) /dev/disk0s16 on /Users (local, journaled) automount -nsl  on /Network (automounted) automount -fstab  on /automount/Servers (automounted) /dev/disk3s1s2 on /Volumes/My CD (local, nodev, nosuid, read-only)
In this case, /Users is a local (not networked) file system, and writable, with /Volumes/My CD is a read-only file system.
NFS mounted disks
In addition, pay attention to file systems that may be mounted over the network using NFS.
Run the mount application as above and look for "type nfs" (on Linux) or for a missing "local" (on Mac OS X).
If a file system is mounted remotely, changing to root does not enhance your permissions, as the permissions of the nfs daemon still apply. It may be worth logging in to the NFS server, and delete the files there.
Linux supports POSIX.2 access control lists using the getfacl and setfacl commands. Check for permissions with
If getfacl can not be found, check the ls man page for "ACL". If it can not be found there, you may assume that access control lists are not (yet) supported on that particular machine.
Mac OS X specific
Below some possible causes are listed.
Your first attempt should be to try it as root:
sudo rm -f file.txt
Your second attempt should be to list special permissions and flags of the file and parent folder:
ls -loe file.txt GetFileInfo file.txt ls -loed . GetFileInfo .
Lock bit set
On a HFS filesystem, each file has a few meta attributes, including the locked and invisible bits. You can inspect these with GetFileInfo, a command line tool that is included in the Developer Tools.
% GetFileInfo file file: "/Users/freek/file" type: "" creator: "" attributes: avbstcLinmedz created: 04/27/2006 16:19:48 modified: 04/27/2006 16:19:48
The capital L signifies that the lock bit is set. Remove it with SetFile:
% SetFile -a l file
The -o option of ls lists the flags of a file:
Possible flags are:
arch set the archived flag (super-user only) opaque set the opaque flag (owner or super-user only) nodump set the nodump flag (owner or super-user only) sappnd set the system append-only flag (super-user only) schg set the system immutable flag (super-user only) sunlnk set the system undeletable flag (super-user only) uappnd set the user append-only flag (owner or super-user only) uchg set the user immutable flag (owner or super-user only) uunlnk set the user undeletable flag (owner or super-user only)
The schng, sunlnk, uchg and uunlnk flags can prevent a user, or even root from deleting a file.
You can change the flag with
chflags noschg,nosunlnk,nouchg,nouunlnk file
You may not be able to remove the schg flag.
You can set the schg flag as root, in a normal Mac OS X Terminal session. But once set, you cannot clear the unless you go into single-user mode. Once in single-user mode, use 'chflags' to turn the schg bit off (as shown above).
Why does it act like this? Well, clearing the schg bit requires that the kernel's 'secure level' be set to 0 or less. In a standard OS X boot, the secure level is set to 1, which restricts certain functions, such as clearing the schg flag. When booted into single-user, the secure level is set to 0, which does allow you to clear to the schg flag.
% sudo shutdown now [ends Aqua and enter single-user mode] % su [become root] % chflags nouchg,noschg testfile [change the two flags I thought responsible] % rm testfile [get rid of it!] % exit [end root] % exit [restart Aqua]
Access Control with ACL
Mac OS X support POSIX.2 access control lists since 10.4. You can use the -e option of ls to display:
% ls -le -rw-r--r--+ 1 juser wheel 0 Apr 28 14:06 file1 owner: juser 1: admin allow write
You can change the permissions with chmod
% chmod +a "admin allow write" file1
See man chmod for more information, especially the section on "ACL manipulation options".
For sake of completeness, ACL does not work until it is enabled on a volume:
% sudo /usr/sbin/fsaclctl -p / -e
Beside the above, possible workarounds include:
- Try as root with sudo
- Boot in single user mode
- Access the hard disk with your computer in Target Disk mode
- Boot in Mac OS 9
- You can't empty the Trash or move a file to the Trash in Mac OS X
- Troubleshooting permissions issues in Mac OS X
For sake of completeness, if you can delete a file in the Terminal, but not in the GUI of Mac OS X, it may be worthwhile to check the permission of the Trash:
# ls -ld /.Trashes /.Trashes/* d-wx-wx-wt 3 root admin 102 12 Apr 22:54 /.Trashes/ drwx------ 2 freek admin 68 12 Apr 22:54 /.Trashes/501/
where the UID of user freek is obviously 501.