A hacker has dropped a file in my tmp dir that is causing issues. Nothing malicious except creating GB's of error_log entries because their script is failing. However, the file they are using to execute has no permissions and even as ROOT I can't delete or rename this file.

----------  1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php

root@servername [/home/wwwusr/public_html/tmp]# rm zzzzx.php
rm: remove write-protected regular file './zzzzx.php'? y
rm: cannot remove './zzzzx.php': Operation not permitted

I have also tried removing by inode

root@servername [/home/wwwusr/public_html/tmp]# ls -il

1969900 ----------  1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php

root@servername [/home/wwwusr/public_html/tmp]# find . -inum 1969900 -exec rm -i {} \;

rm: remove write-protected regular file './zzzzx.php'? y
rm: cannot remove './zzzzx.php': Operation not permitted

How do I delete this file?

  • 15
    Were I you, I'd be looking to nuke and pave that box. It clearly has at least one security hole, which is bad enough that someone can write new files with custom permissions outside the document root, and then on top of all that, manage to get PHP/Apache to try and load it. My friend, you are royally pwned. If you want that box back, you've got to nuke it from orbit. It's the only way to be sure. Jan 23, 2013 at 22:42
  • Thanks Warren. This is actually a brand new box moving over accounts that have never been compromised before. I'm trying to figure out what the settings are that are different (both CPanel boxes).
    – Bradley
    Jan 28, 2013 at 5:00
  • 2
    Just because the OS is recent and the install fresh doesn't mean you cannot have a compromise. A bug detected today in an OS that shipped 6 months ago may persist for years, as people continue to install the older OS from CDs that are continually getting older. Even if there is a patch for the flaw, the window between installation and update allows the compromise. Setting that aside, if I am wrong that some bad actor placed that file on your system, a conscientious sysadmin would have to at least try to explain its presence in another way. Jan 28, 2013 at 5:19

2 Answers 2


The file has probably been locked using file attributes.

As root, do

lsattr zzzzx.php

Attributes a (append mode) or i (immutable) present would prevent your rm. If they're there, then

chattr -ai zzzzx.php
rm zzzzx.php

should delete your file.

  • I would avoid calling them extended file attributes, as it could cause confusion with the extended file attributes as set with setfxattr and used to store ACL or SELinux... attributes. Jan 23, 2013 at 20:06
  • @Stephane Chazelas - ok. Does plain 'file attributes' work for you? Jan 23, 2013 at 20:07
  • 1
    I can't think of anything better. They used to be ext2 file attributes but they are now supported by other FS on Linux like xfs of btrfs, so one can no longer call them that. Jan 23, 2013 at 20:11

Unfortunately Warren didn't post as an answer but as a comment; I can't emphasise enough that he's totally correct.

Removing/changing one file won't fix your REAL problem; it will make ONE symptom go away. Take the box offline, take an image for later forensics, and re-install, with a newer version (hopefully w/ new security fixes) of whatever you were running.

I repeat: deleting the file is NOT A FIX.

  • 7
    I didn't post an answer because my comment doesn't answer the asked question. Jan 23, 2013 at 23:46
  • Heh ... I guess I'm still too new to the stackexchange way of doing things. I'd rather get down voted for "not answering" than not saying what needs to be said ;D
    – tink
    Jan 23, 2013 at 23:55
  • The question isn't about fixing that problem, it's about removing a file with no permissions. And it's an interesting question!
    – wim
    Jan 24, 2013 at 1:55
  • 5
    @tink: That's what comments are for: to say things that need to be said, which are not answers to the question. Jan 24, 2013 at 2:05
  • Obviously this does answer the question that was asked. Wiping the disk will remove the file! Ordinarily it is not a reasonable method of removing a file, but in this case, it is the most reasonable way, because it solves the underlying problem at the same time. (Furthermore, even if this did not literally answer the question as it was explicitly asked--which it does!--it's not wrong to post a solution to an OP's actual problem.) May 12, 2015 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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