48

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.

50

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.

  • 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 0:08
9

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.

  • 'chmod ugo+w filename" totally did the trick for me – Alfishe Aug 12 '17 at 1:17
1

'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

protected by Community Jun 29 '18 at 13:07

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.