38

I have directory exam with 2 files in it. I need to delete files but permission is denied. Even rm -rf command can't delete these files. I logged in as a root user.

enter image description here

1
  • 19
    (1) Please post text from the Terminal as text if at all possible.  Ideally, copy and paste it.  If you have no way of capturing the text except manually transcribing it, then do that, but disclose that you are doing it, and include the screen capture image so we can double-check your typing.  (2) When you have a question about permissions, please, always, do ls -la, so we can see the permissions on . (the directory). May 31, 2015 at 5:43

2 Answers 2

70

From root user check attributes of files

# lsattr 

if you notice i (immutable) or a (append-only), remove those attributes:

# man chattr
# chattr -i [filename]
# chattr -a [filename]
3
  • 2
    Wow, that was a tricky one. Thank you for posting this solution; I was at my wits' end. I was pretty sure that this was somehow related to my unison synchronisation; it was left in an 'unknown' state (due to many reasons), and this meant that those directories I couldn't delete were set (by unison) to be append-only (this is typical of unison). But I had no clue how to view/reset that append-only mode! You were a lifesaver; I hope the original poster also had their problem solved. May 20, 2016 at 19:30
  • 1
    This is a Lifesaver.
    – Luka
    Apr 3, 2018 at 18:40
  • And five years later, I stumble upon the same issue, and fortunately, your answer was still here to save my troubled life... @Invoker thank you again and again! Sep 6, 2021 at 17:28
23

The most common reason for rm complaining that you don't have permission to delete a file, is that the permissions on the directory forbid you from deleting the file. In order to delete a file, you need write permission on the directory. The permissions on the file are irrelevant (rm without -f prompts for confirmation before deleting a read-only file, but that's just a confirmation, not a limitation). On some Unix variants such as OSX (but not Linux), the ACL on a file can prevent its deletion; ls -l would show @ at the end of the permission field if there was an ACL entry on the file.

Access as root bypasses permissions, so root can delete files even in a read-only directory.

The output from ls -l shows a . at the end of the permission column. This indicates that the file has an SELinux security context. Unlike basic permissions and ACL, the SELinux security context on a file can control who is allowed to delete it. Furthermore SELinux cannot always be bypassed by root (it's possible to have a process running as user ID 0 but with as few rights as the SELinux policy designer chose). To see what the SELinux context allows you to do, run ls -lZ . exam_a.

Another thing that can prevent a file from being deleted is if it or the directory that contains it has the append-only or immutable Linux attribute. Run lsattr -d . exam_a to view the Linux attributes. If the a or i attribute is on, you'll need to remove it (chattr -a -i . exam_a) in order to delete the file; only root can do that. Root cannot bypass these attributes to delete a file, the attributes have to be turned off first.

Yet another thing that prevents a file from being deleted is if the filesystem is mounted read-only, but you'd get a different error message in that case.

You must log in to answer this question.