7

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.

ron
  • 6,575
  • 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? – Rui F Ribeiro Jun 09 '17 at 19:05
  • looks suspiciously like a chattr +i situation; confirm with lsattr sort5BtEdh – Jeff Schaller Jun 09 '17 at 19:27
  • lsattr sort5BtEdh responds with ---------------- as does many of the other files under /tmp and elsewhere. – ron Jun 09 '17 at 20:46
  • the context is server handed off to me, boot and don't get graphical console window for login just prompt. But it is run level 5. I change splash to verbose, watch various services fail during boot including file access errors to some .pid files and other files under /tmp. Bunch files under /tmp are owned by gdm.gdm, figured i'd start cleaning out /tmp and as root and cannot delete files. – ron Jun 09 '17 at 20:48
  • as root I can create a text file under / and delete it. Umask is 0022. Kernel is 3.0.101-71.1.10690.1.PTF-default #1 SMP – ron Jun 09 '17 at 20:57
  • /dev/sda1 on /boot type ext3 (rw,acl,user_xattr) – ron Jun 09 '17 at 20:57
  • /dev/sda2 on / type xfs (rw) and /etc/fstab has LABEL=root / xfs defaults 1 1 – ron Jun 09 '17 at 20:57
  • Can you show us the output of cd /tmp; ls -ld .; df . – Mark Plotnick Jun 09 '17 at 21:15
  • Can you create files in /tmp ? Can you remove what you create? – Mark Plotnick Jun 09 '17 at 21:15
  • 3
    Possible duplicate of How does the sticky bit work? – GAD3R Jun 09 '17 at 22:00
  • 3
    @GAD3R the sticky bit doesn’t affect root. – Stephen Kitt Jun 12 '17 at 07:28
  • SLES comes with AppArmor, a path-based mandatory access control system on top of the "usual" discretionary access control. Is it active? If yes, are there rules regarding /tmp? Otherwise, maybe SELinux active (which would be unusual but not impossible for SLES)? – countermode Jun 12 '17 at 07:57
  • so AppArmor is installed and was active. But there was no profile for anything /tmp related. I also went into Yast AppArmor Configuration and unchecked Enable Apparmor then rebooted. Problem persists. – ron Jun 12 '17 at 14:06
  • 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 – Luciano Andress Martini Jun 14 '17 at 13:32
  • @ron : I guess you finally found what caused your problem within your /tmp mount options. Could you post it as an answer to help everyone avoid this problem? – dan Mar 26 '18 at 11:23
  • i never did find a solution, what i did was reformat the hard disk and reinstall the operating system from DVD; in the end there were other reasons and benefits for reinstalling the OS that made me go this route which obviously addressed the weird issue where i could not delete certain files. – ron Mar 26 '18 at 15:22
  • no answers in these posts let me delete those files under the /tmp directory, i got annoyed with the issue then had other needs regarding the server and software on it so best solution became just take an hour to reinstall the OS which then removes any possibility of an underlying problem be it intended or unintended. – ron Mar 26 '18 at 15:27
  • related: https://stackoverflow.com/questions/26263267/cannot-move-or-delete-files-even-after-chown-and-chmod – David Cary Oct 13 '21 at 16:39

2 Answers2

12

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.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Luciano Andress Martini
  • 6,628
0

Likely your immutable flag is set.

https://en.wikipedia.org/wiki/Chattr#In_Linux_systems_.28chattr_and_lsattr.29

user235409
  • 24