How to delete “nobody” files from a directory I own in FreeBSD?

Lazyweb, here’s a quick question for you. On a FreeBSD system, suppose I own a directory called “foo”. Inside that “foo” directory are some files (file1, file2, file3) owned by the “nobody” user. How do I delete those files? When I type the command “rm file1” I get the response “rm: file1: Permission denied” even though I own the parent foo directory.

Any suggestions? It’s on a machine where I don’t have root access.

Update: Problem solved, but in an annoying way. The files were created by a PHP script, so I wrote a new PHP script to remove the files in question. It looked something like



This forum thread from 2001 describes the idea (thanks to Mark and the people that commented).

In case you’re wondering, pair Networks’ FreeBSD systems really don’t work well with the WordPress “WP Cache” or “WP Super Cache” plug-ins, because both plugins make files owned by the “nobody” user which appear to be impossible to delete from the SSH command-line.

38 Responses to How to delete “nobody” files from a directory I own in FreeBSD? (Leave a comment)

  1. Matt,
    I have no idea, but I did see a tech savvy friend tweet this once:

  2. Are you sure you have write permission on directory ‘foo’?

  3. it simple

    if apache runed under “nobody”
    just download any webshll like on server
    go to browser and type
    and delete files

    after that remove r57shell from server

  4. You own the directory, but ‘nobody’ owns the files, so if the permissions are set restrictively, which they appear to be, as far as I know you’d need to either sudo (if you can), or su to nobody (if you know nobody’s password) to rm the files. I’m not an FBSD user, so hopefully this isn’t just some nonsense you already know but that doesn’t act the same on BSD, but I don’t see how it could be that different.

  5. Hi Matt,

    This page seems to have some solutions to the problem.

    The basic idea is to create a small CGI script or PHP program and run it from a web browser. Since Apache or whatever web server you are running will normally be running as the “nobody” user, it should be able to nuke those files with no problem.

    So if you created a PHP script called nuke.php that deletes those files and copied it to the root of your site, you could just run “” from IE or Firefox or , heaven forbid, Chrome 😉 and get rid of the files.


  6. Hi Matt,
    are this files created by Apache? If they’re, you can delete them with a PHP script.

    For example, a PHP Script hosted on this FreeBSD ( that make some: unlink(‘path/file’);

  7. Haha, pelmen ftw. Apache should surely be able to delete them, having apparently put them there, so yeah maybe just a litlle php unlink() oneliner would do it.

  8. If you have write permission to the directory, you should be able to remove the files inside of it even if you don’t own them. Can you show the output of ls -l? Are you sure you have write permission on that dir?

  9. If what Sean is saying is the case, then I think you want to know what ‘ls -ld foo’ is, as opposed to ‘ls -l’. If you don’t have write permission on the directory, but own it, you should be able to give yourself permission to write on it with chmod.

    (ok, im done)

  10. Also could be ACLs in use, I suppose.

    Been a few years since I’ve worked much with FreeBSD, there may be something else I’m forgetting…

  11. Actually the permission and / or owner of the files you want to delete have no influence at all. I just deleted a file owned by user nobody, group nobody with permissions 000 (no permissions for anyone) on my FreeBSD system.

    Removing a file is a modification on the directory not the file. So you need the right permissions there. So ‘chmod u+w foo’ and it should work. If it still doesn’t try ‘rm -f ‘ (-f = force) By default rm is supposed to ask for confirmation if you try to delete a file with improper permissions but maybe this system just skips this step.

  12. cd /foo
    chown -R user:group ./
    chmod -R 777 ./
    rm -R ./

    OK, that will also delete the /foo directory and everything in it, but you can | and grep for the file types that you’re looking to kill. Maybe something like this….but be careful!

    for i in `ls -l | grep drwx | awk {‘print $9’}`; do echo $i && rm ./$i | wc -l; done;

  13. Ed Shaz, that’s a perforce command, but thanks for the thought.

    Willem Joosten, I definitely have write permission on the “foo” directory.

    pelmen, I seriously almost did that. I ended up making a removenobody.php script that removed the files in question. There were a bunch, and PHP sucks at removing lots of files at once. You can’t say unlink(“file*”); for example. So it wasn’t fun.

    rupa, both sudo and su are locked down, so I couldn’t use either.

    Mark/Oriol, that’s pretty much what I did. I used unlink/rmdir instead of system, but that’s about the size of it. Thanks for the link.

    Sean/rupa, I played around with ACLs a bit but didn’t see anything especially weird. On Linux sometimes lsattr will tell you that a bit has been set to make a file undeleteable, and then chattr can fix it. But even though I owned the parent directory, this FreeBSD system wouldn’t let me delete the files within the directory.

    Willem Joosten, the pair Networks machine must have been configured differently.

    mercutiom, trying to chown would return a message such as “chown: ./meta/wp-cache-883dcd3fd4f45ce596d5e8ccff27ba35.meta: Operation not permitted”

  14. I guess I was trying to highlight this part:

    “Deleted files can be resurrected by syncing them to a prior version.
    The only way to permanently remove a file is to use the p4 obliterate command. This command is irreversible and expensive, so it is only available to those with admin access.”

  15. Yup, but that’s still source-code control, Ed Shaz. I’ve used perforce before, but this was more of the pure filesystem issue and not a source control issue. I do appreciate you commenting though.

  16. Have you tried:

    >su nobody
    >rm -Rvf file1

  17. When ‘ls -lo’ doesn’t show ‘uunlnk’, ‘sunlnk’ or a plus-sign at the end of the permissions (like -rw-r–r–+) than the file doesn’t have acl’s or special flags applied.

  18. Oops, I see you did. Sorry.

  19. @Matt: by ‘the pair server must have been configured differently’ do you mean you had this problem on one of their servers or did you check my site / provider? In the later case: I tested on my development bsd machine with root access 🙂 In the former case: it should work, do it all the time on shared hosting accounts at Pair. Also it’s pretty easy to run PHP using your own account instead of nobody. So you don’t get this kind of problems in the first place.

  20. Any self-respecting programmer would simply “ownz the box”
    nice work around though…

  21. Didn’t read the update at the top of the. This problem does occur at Pair. Strange….

  22. I’ve dealt with this quite a bit before, and do tech support for web hosting… so I’ve got some background.

    As others have pointed out, the reason is because Apache runs as user “nobody”, and php is an Apache module, hence runs under Apache. You’ve got a few options:

    1. If you have full access to the box, obviously sudo.
    2. You can use a web shell, simply make sure your scripts clean up after themselves.
    3. Run your PHP as a cgi. Most webhosts allow this. You need to ask your web host for exactly how as it can vary slightly (due to paths). Note there are security issues to be aware of:
    4. You can use something like suPHP, which is the PHP equivalent of suEXEC. Your host would need to do this obviously. It is slower, since cgi is inherently slower… but it does work and let users keep perms on their own files.

    That’s really about all you have.

    I should note that wp-cache and wp-super-cache have the ability to clear cache via the settings in wp-admin. That should purge the files. It does so using unlink() so it should remove just like the script you wrote.

  23. @Matt

    Why are you saying deleting a bunch of files at once in PHP is hard? It’s a 3-liner to loop through glob… Or a one-liner to do a system call. Sure, perl gives you a one-liner with their built in glob syntax, but a foreach loop isn’t something to stress over.

  24. “There were a bunch, and PHP sucks at removing lots of files at once. You can’t say unlink(”file*”); for example. So it wasn’t fun.”

    For future reference:

    $files = glob('file*');
    foreach($files as $file) { unlink $file; }

  25. Robert Accettura, thanks for stopping by and giving the rundown. I did try to delete expired/cached files in wp-super-cache, but there were still a few left lying around.

  26. When I host people’s sites (which I do, but only on a very small scale, mostly to keep myself up to date with the nuts and bolts of it), I set things up so that they have a private apache instance which runs under the same user id they log in with. This consistency means there’s no need for dangerous world-readable or even world-writable workarounds.

    This is how things should be. But once upon a time, there were too many ways to get root on the typical Unix box if you had a user account. And because the process of resolving those security holes took so long, people went for stupid workarounds like “nobody” accounts and chroot jails (well, those have some merit) and, worst of all, PHP “safe” mode, which tries to do the operating system’s job by restricting what the user can do from within PHP itself.

  27. Hi Matt,

    I notice that your feed just switched to snippets instead of full-text. That sucks. Can you make it go back to the way it was before? Thanks!

  28. Matt,

    You may wish to look at this issue too 🙂

    WordPress has some SERIOUS (security) issues , by Mike Dammann.

  29. About saying you can do “unlink(”file*”);” while that is true, using the Directory Iterator class (if you have PHP5) is pretty simple to batch delete files in a foreach loop. Either way you have a solution, just thought I’d deposit my 2 cents.

  30. @Harith 12:33am – The article your link goes to is on a site running WordPress 2.3.3 (see the source code). WordPress is on 2.6.2. Perhaps he’s getting hacked because he’s not upgrading his installation with the latest security patches?

    All code has vulnerabilities. WordPress has been good about fixing them, but they can’t force people to update their own installations.

  31. its a good idea to remove the version number from any wp inatallation as it makes searches for posible targets harder.

  32. Harith, I think WordPress is so popular that it’s inevitable that WP is a pretty big target for hackers. What bothers me is the need to upgrade my software whenever there’s a new security hole–that plus this annoying “it takes forever to clean up the junk left behind by WP Super Cache” issue had me taking a fresh look at Blogger this past weekend.

    I store my data in the cloud for most services these days precisely so I don’t have to worry about security issues or keeping my software up-to-date. If Blogger had a few more options (ability to do different permalink url vs. title, better WordPress importing ability, more flexibility with comments), it would be pretty tempting. Some of the stuff at Blogger in Draft is looking pretty neat.

  33. @ceejayoz
    You’re right, I’ve been way behind and just upgraded. The blogs using the WordPress platforms which have been hacked however were not mine and some of those were using this latest version as well.
    Wordpress has been and is a step behind when it comes to security.
    Switching to Blogger because of it?
    Nah, I think I’ll pass. 🙂
    Matt Mullenweg has admitted to a need to make upgrades easier in a recent interview with me, but downplayed the security issues.
    I see major issues coming up knowing that more and more hackers become aware of the fast benefit from hacking authority blogs.
    I have also seen some quality blogs get penalized. One example from not too long ago would be the v7n blogs disappearing from the Google index, but there are many more out there which don’t make it into the “SEO headlines”.
    This is not just a WordPress issue, it’s also a Google issue as SERPs are getting manipulated and ranking in Google seems to be THE motivator to hack the blogs to begin with.

    ~ Mike Dammann

  34. You can delete files owner by user “nobody” if you are logged in as root.

  35. Fellow Pair user here. There really is no better web host out there, IMO. Yeah, there are hosts that use chrooted jailed environments, Pair doesn’t and they have their reasons, one being scalability.

    Check out php-cgiwrap:

    I’m running WP, Drupal and Gallery with that setup without any problems.

    You can tighten down permissions pretty good then too because directories can be set at 701 (or you can just leave them at 755) and any php files can be set to 600.

    You can also use cgiwrap for any cgi scripts you have and Pair is also working on testing suEXEC, so hopefully, those of us not on dedicated servers will be able to run pretty much everything under our own user account and not ‘nobody’.

    Go ahead and hit, a community driven site hosted by a Pair user. The username and password are the same as accessing their newsgroups. Just log into your account via SSH and it’s displayed there. Search for ‘security’ and ‘permissions’ and you can read up on all kinds of info about tightening up your account at Pair.

  36. Is the directory ‘sticky’? See ‘man sticky(8)’.

    From ‘man chmod(2)’:

    If mode ISTXT (the `sticky bit’) is set on a directory, an unprivileged
    user may not delete or rename files of other users in that directory.
    The sticky bit may be set by any user on a directory which the user owns
    or has appropriate permissions. For more details of the properties of
    the sticky bit, see sticky(8).

  37. I had this same issue after running plogger on my Pair Freebsd server. I had about a 100 .jpg’s owned by user nobody in different subdirectories.

    I discovered that the Pair machine didn’t like chmod, chown or shell script exec from cgi. So I ssh’d to the server and built a list of the files using find. Something like this:

    find / -user ‘nobody’ > nobodylist.txt

    Then I wrote a short PHP script that assigned the list to an array, and used a foreach loop to unlink each file. Using find for the recursion was simple, and having the text file gave me something to eyeball before running the script. This way I run the shell command with my username and do the unlinking as user nobody.

  38. You can delete files owner by user “nobody” if you are logged in as root.