69

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.

3 Answers 3

83

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.

5
  • 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, 2017 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, 2018 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, 2018 at 0:08
  • 1
    chattr -i -a worked.
    – xji
    Oct 5, 2019 at 0: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 8, 2019 at 16:04
18

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.

1
  • 'chmod ugo+w filename" totally did the trick for me
    – Alfishe
    Aug 12, 2017 at 1:17
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .