working on a server, operating system is SLES 11.4 x86-64. There are many files, and folders, under the /tmp directory. As root, I cannot remove anything under /tmp. Such as rm -f sort5BtEdh or rm /tmp/sort5BtEdh it returns rm: cannot remove /tmp/sort5BtEdh : Operation not permitted.

what would cause this, and how do i make it so the root user at least can delete files and folders under /tmp ?

also, much is owned by root.root. Other files and/or folders is owned by gdm.gdm and also by my user account ron.users

Even if I su or login via ssh or sit at the console, as the owner of the file, I get the same result operation not permitted on anything under /tmp.

  • 1
    I assume you are not telling us the context. Why are you trying to delete files? Does writing a file in / work, for instance? Jun 9, 2017 at 19:05
  • looks suspiciously like a chattr +i situation; confirm with lsattr sort5BtEdh
    – Jeff Schaller
    Jun 9, 2017 at 19:27
  • 3
    Possible duplicate of How does the sticky bit work?
    – GAD3R
    Jun 9, 2017 at 22:00
  • 3
    @GAD3R the sticky bit doesn’t affect root. Jun 12, 2017 at 7:28
  • 1
    Is /tmp mounted externally? Can you post the result of mount command without any arguments? And by the way, what is the result of this command: file /tmp/sort5BtEdh ? And fuser /tmp/sort5BtEdh Jun 14, 2017 at 13:32

2 Answers 2


First possibility is that the immutable flag is on. You can change this behavior using the command chattr -i filename to allow the changes to the file.

But maybe you are running a filesystem with errors; this can make your filesystem become read only entirely or for certain files. Troubles with the RAM can emulate this problem, too. This can be fixed when you reboot the server and runs fsck, but sometimes the server can fail to start and data can be lost when the reboot operation tries to synchronize the information in your RAM to the disk during the restart. If dmesg shows that you are running with memory or filesystem errors, I would recommend a data backup before the reboot, if that is possible. Sometime bad addresses of memory are given by the kernel due to hardware troubles, and some bad data can go to the disks when the system restarts. A crazy kernel is worse than a kernel in panic, and can do some unexpected behaviors like write in your MBR, or important files; it is rare but possible in bad hardware, particularly if you run with bad RAM or with a hot processor. In Brazil, we have a large amount of bad hardware that can cause that. Note: If the trouble is with the RAM memory, don't run FSCK -- it will do crazy things.

UPDATE: Because you're saying you are having troubles only with tmp there is a chance that tmp is being mounted in another partition (with errors perhaps?) or externally (samba, nfs?), so in this case we need more information about your mounted partitions. If that is the case, post the result of your mount command without any arguments.

  • 1
    Good call. My issue was an application had a mount in my tmp directory!
    – Shadoninja
    Feb 13, 2020 at 21:20

Likely your immutable flag is set.


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.