3

Haven't been here much. Mostly Stackoverflow. Anyway, I have a file that I can't remove.

I tried sudo rm files.db and got

Operation not permitted

Did sudo chown me: files.db

Then sudo chmod 777 files.db

Tried sudo rm files.db again and got same result.

ls -l produces:

-rwx------  1 me  staff  34177024 Jun  6 23:58 files.db

I had hoped to see:

-rwxrwxrwx  1 me  staff  34177024 Jun  6 23:58 files.db

Tried sudo chflags noschg files.db

Then sudo chmod 777 files.db and then still got:

-rwx------  1 me  staff  34177024 Jun  6 23:58 files.db

What am I missing?

UPDATE:

Tried su user rm -rf files.db put in my password and got:

su: Sorry

I used this drive for Time Machine backups.

Isn't there some way to force a removal?

ANOTHER UPDATE:

Not sure how this works but tried ls -i and got:

5482053549 files.db

Then find . -inum 5482053549 -delete and got:

find: -delete: unlink(./files.db): Operation not permitted

Also tried find . -inum 5482053549 -exec rm {} \; and got:

rm: ./files.db: Operation not permitted

Ugh.

LAST UPDATE:

This morning I did the following: chown me folder and then chmod 777 folder. I was then was able to delete the file.

Mateusz Piotrowski
  • 4,773
Jay
  • 131
  • 1
  • 1
  • 5
  • 1
    What's the filesystem this is on? Is it a networked one? (The file server could easily say "I'm not letting you change this, no matter who you are".) – Ulrich Schwarz Jun 07 '13 at 04:27
  • Yes, it is a 1T drive I use to backup some work. I've deleted many other files from the drive. So maybe if I connect it directly it may work? I'll give it a try in the AM... gotta hit the sack. Thanks. – Jay Jun 07 '13 at 04:31
  • 4
    Do you have write permission on the directory? Is the file in use? – tripleee Jun 07 '13 at 07:21
  • 2
    su requires the root password, not your own password. – tripleee Jun 07 '13 at 07:23
  • 1
    if you do a lsattr on the file is the immutable attribute set on the file? The tip-off for me was the fact that you're sudo'ing to root and it's still denying you. root has CAP_DAC_OVERRIDE (or whatever the equivalent on OS X is) so I don't think it's a permissions issue. On Linux immutable is handled by a separate CAP_LINUX_IMMUTABLE capability which only affects chattr invocations. There's probably a similar idea in the BSD/OS X world. – Bratchley Jun 07 '13 at 12:46
  • @tripleee you had the answer. If you enter it as an answer, I'll credit you with the answer. Thanks. – Jay Jun 07 '13 at 15:16

1 Answers1

2

Did you also try chflags nouchg, or did you check if some parent directory had a uchg or schg flag?

$ mkdir 1; touch 1/2; chflags uchg 1; sudo rm -f 1/2
rm: 1/2: Operation not permitted
$ chflags nouchg 1; rm 1/2
$

If there wasn't write permission to the directory, the error message would usually be Permission denied instead of Operation not permitted:

$ sudo mkdir 3; sudo touch 3/4; sudo chown $USER 3/4; rm 3/4
rm: 3/4: Permission denied

sudo rm normally works even if the delete or delete_child operations are denied:

$ touch 4; chmod +a 'everyone deny delete' 4; rm 4
rm: 4: Permission denied
$ mkdir 5; touch 5/6; chmod +a 'everyone deny delete_child' 5; rm 5/6
rm: 5/6: Permission denied
$ ls -lde 4 5
-rw-r--r--+ 1 lauri  staff    0 Jun  7 12:44 4
 0: group:everyone deny delete
drwxr-xr-x+ 3 lauri  staff  102 Jun  7 12:44 5
 0: group:everyone deny delete_child
$ sudo rm 4 5/6
$
Lri
  • 5,223