71

I am in the process of migrating a machine from RHEL 4 to 5. Rather than actually do an upgrade we have created a new VM (both machines are in a cloud) and I am in the process of copying across data between the two.

I have come across the following file, which I need to remove from the new machine but am unable to, even when running as root:

-rw-------  1 2003 2003  219 jan 11 14:22 .bash_history

This file is inside /home/USER/, where USER is the account of the guy who built the machine. He doesn't have an account on the old machine, so I am trying to remove his home folder so that the new machine tallies with the old one, but I get the following error:

rm: ne peut enlever `.bash_history': Opération non permise

(translated from the French: cannot remove XXX, operation not permitted)

I have tried using the following command but this has made no difference:

chattr -i .bash_history

Is the only choice to create a user with the ID 2003, or is there another way around it?


Edit

I have tried using rm -f, and I get the same error. I get the same kind of error using chmod 777 first.

I have been able to chown the folder that contains the file I am trying to delete, so it is:

drwx------ 2 root root 1024 jan 24 15:58 USER

Edit2

Running the lsattr command as suggested by Angus gave the following output:

-----a------- USER/.bash_history
------------- USER/..
------------- USER/.

The file is flagged as append-only - on changing this flag using chattr -a .bash_history I was able to delete the file.

Rich
  • 4,529

4 Answers4

86

Check the permissions of the directory. To delete a file inside it, it should be writable by you

chmod ugo+w .

and not immutable or append-only:

chattr -i -a .

Check with ls -la and lsattr -a.

angus
  • 12,321
  • 3
  • 45
  • 40
  • thanks.. I had to run this on named* files that didnt not clean up after yum erase bind in Centos 7 minimal – onxx Mar 19 '17 at 19:49
  • Unfortunately, for /vendor/laracasts/generators/.git/objects/pack/, when I run chattr -i -a ., I get chattr: Inappropriate ioctl for device while reading flags on ., and I can't rm the pesky .idx file that Composer left behind (because "Operation not permitted"). – Ryan May 24 '18 at 23:48
  • Ahhh, one workaround for me was to exit out of my Laravel Homestead Vagrant VirtualBox back into Windows 10 (still using Git Bash) and rm the files from there. Then composer update was able to complete. – Ryan May 25 '18 at 00:08
  • 1
    chattr -i -a worked. – xji Oct 05 '19 at 00:18
  • 4
    Even after using Linux for nearly 10 years, I keep on learning new stuff. Never heard about the immutable attribute before! – marlar Nov 08 '19 at 16:04
20

I had a similar problem but had tried both permissions and chattr previously to no avail. Root in Terminal. CD to Directory.

However what worked for me was to check permissions of directory where troublesome file was located - if ok proceed to:

chmod ugo+w filename

this failed - then:

chattr -i -a filename 

which was accepted - then

chmod ugo+w 

which was accepted

rm filename

and it was gone.

Fedora 25 on hp workstation.

2

'sudo' can run the 'rm' command using the same user.group

NOTE: not sure if this will also work for ids like you have.

Example:

ls /path/to/dir_being_deleted
  drwxrwxrwx 2 nfsnobody nfsnobody   4096 Mar  8 06:55 .
  drwxrwxrwx 7 nfsnobody nfsnobody   4096 Mar  8 06:57 ..
  -rwxrwxrwx 1 nfsnobody nfsnobody      0 Mar  8 06:55 filename.txt

sudo -u nfsnobody -g nfsnobody rm -rf /path/to/dir_being_deleted
awltux
  • 241
  • 2
  • 2
0

To add to the answer using chattr, I ran into this issue myself when trying to remove an unwanted directory and found that using

chattr -RVf -i <directory>

solved my issue.  The directory had dozens of folders inside, several levels deep, and

lsattr -la *

showed me that the majority of the subfolder contents were still immutable despite running a basic chattr -i -a <directory> as mentioned by others here.  I found the -RVf options when I finally read the man chattr.  Whoda thunk reading the directions...

Luke
  • 1