File can't be moved by root on OS X

Question

I tried to move a few files to a subfolder on OS X. One refused to move. It said Operation not permitted. I tried again as root:

$ sudo mv file subfolder/
mv: rename file to subfolder/file: Operation not permitted
$ sudo mv file filex
mv: rename file to filex: Operation not permitted
$ lsattr file
lsattr: Inappropriate ioctl for device While reading flags on file

I tried lsattr on other files; all files I tried gave me the same message: Inappropriate ioctl for device While reading...

Coming from Linux, I did not know about flags so here is the output of ls -leO@ file:

$ ls -leO@ file otherfile
-rwxrwxrwx  1 eeytan  staff  uchg 79549 Nov 11  2010 file
-rw-r--r--  1 eeytan  staff  -     5071 Sep  7 02:37 otherfile

I tried the OS X Disk Utility; it said there were no errors on my disk. What's going on here?

lsattr isn't a standard OS X command; try ls -leO@ instead. Also, what volume is the file on? Try mount to see what attributes the volume is mounted with. — Gordon Davisson, Sep 09 '13 at 19:10
@GordonDavisson, it seems you're on the right track. ls -leo@ says that file is the only one with the "uchg" attribute, which sounds a lot like "unchangeable" to me. — eje211, Sep 09 '13 at 19:13

score 97 · Answer 1 · edited Oct 24 '17 at 09:53

97

For people stumbling upon this in an OS X 10.11+ era (El Capitan or newer): Apple has added a whole new layer of security in OS X. They have taken away some privileges from root. The file you are trying to modify has a restricted flag. Only restricted processes which are signed by Apple will be able to modify these files. However, you can disable this security system by booting in recovery mode and disabling it in a Terminal by doing: csrutil disable.

Alternatively, you can also just start Terminal in Recovery Mode and delete the file there. Or even try booting in a Linux environment with HFS+ support (at least if you're not on APFS yet) to change the file.

edited Oct 24 '17 at 09:53

mb21

519

answered Sep 01 '15 at 23:56

Martijn Courteaux

1,705

3

What does the csr in csrutil stand for? – Michael Terry Jul 09 '16 at 18:32
18

I believe it was Benjamin Franklin who said "Those who sacrifice ease of use for security deserver neither". Or something. – dmgig Jul 21 '16 at 15:02
Do you mean start the computer in Recovery Mode? – rraallvv Aug 24 '20 at 12:43
Try the other answer first. – cambunctious Jan 17 '21 at 22:03
FYI you can determine if a file has the restricted flag with /bin/ls -lO – deed02392 Mar 15 '21 at 00:36
People make inappropriate sacrifices to get insufficient security because of unclear ideas (and implementations) of security. For instance, the OS gives code all abilities of the user. So if there's a virus inside a utility or library used by root, it can do anything... so they restrict what root can do. – SteveWithamDuplicate Oct 05 '22 at 21:27

score 43 · Accepted Answer · answered Sep 09 '13 at 19:25

43

Sounds like the file is locked to me, which is why the uchg attribute is appearing. You should be able to use the following command to remove the locked attribute:

chflags nouchg file

or right-click the file in the Finder, click "Get Info" then uncheck the "Locked" checkbox

answered Sep 09 '13 at 19:25

binarybob

9,875

2

Ha! It looks like you answered your own question just as I was posting this answer! – binarybob Sep 09 '13 at 19:27
Thanks a lot! I hadn't noticed the lock icon! I have to use Finder sometimes rather than sticking to the terminal :P – Thanasis Petsas Aug 06 '21 at 00:11

score 10 · Answer 3 · edited Mar 22 '16 at 18:09

10

Try:

chflags -f -R nouchg directory

on a higher level directory to stop this problem.

edited Mar 22 '16 at 18:09

kenorb

12,695

answered Nov 24 '15 at 22:55

dvand

109

1

FWIW: I had this problem zsh: locking failed for /Users/me/.zhistory: operation not permitted: reading anyway and running this command on my home directory fixed it – raine Dec 04 '17 at 16:27

score 3 · Answer 4 · answered Mar 19 '19 at 16:45

I had a file I couldn't delete in terminal:

$ sudo ls -leO@ [email protected]/Documents/.%cb_defense/cb.doc
-rw-rw-rw-  1 root  wheel  - 41984  1 Mar 11:20 [email protected]/Documents/.%cb_defense/cb.doc

$ sudo rm -rf [email protected]/Documents/.%cb_defense/cb.doc
rm: [email protected]/Documents/.%cb_defense/cb.doc: Operation not permitted

What worked for me was opening Finder and deleting the containing directory whole. The way I understand it, Finder deletes directories as a unit entirely disregarding their contents, so it's not subject to the same restrictions as regular rm -rf.

score 1 · Answer 5 · answered Jan 21 '16 at 02:35

1

I had this issue too, and I discovered that the folder the file was in was locked. So make sure that's not true. Do 'get info' on the folder in the finder, and make sure the locked checkbox is not checked.

answered Jan 21 '16 at 02:35

abbaroo

11

score 1 · Answer 6 · answered Jun 25 '20 at 15:12

1

Under OS 10.15 this worked for me:

Recovery mode: command + R
Utilities -> Terminal
rm -r /path/to/file/or/dir/to/remove (The -r alone worked for me -- If you need it rm -rf force mode)
Reboot

answered Jun 25 '20 at 15:12

Kim Miller

141

-fdoesn't force anything, it just answers some permission questions with y automatically. – nohillside Jun 25 '20 at 15:14

score 1 · Answer 7 · answered Aug 28 '20 at 22:38

A previous answer said to use:

chflags -f -R nouchg directory

There are two different attributes that prevent changing a file. "uchg" prevents the user from changing the file; "schg" prevents the system from making a change. Use ls -le0@ to see which is your problem, or use apple-I: if "locked" is checked but not greyed out, then "uchg" is set. If "locked" is checked AND greyed out, then "schg" is set.) If "uchg" is set, the previous answer will work. If "schg" is set, then do this instead:

chflags -f -R noschg directory

score 1 · Answer 8 · answered Nov 28 '21 at 23:41

1

Before using arcane commands, confirm your System Preferences

Terminal may not have permission to access your present working directory.

Note your path (e.g. in Terminal, type pwd).
Visit System Preferences > Security & Privacy > Privacy > Files and Folders
Confirm there is a check mark next to any volumes and directories that appear in your path.

If Terminal has permissions and the command still gets an error, check the solutions provided in other answers.

answered Nov 28 '21 at 23:41

Kay V

492

That was my problem - thanks! VSCode and the terminal inside didn't have permissions. – Mieszczańczyk S. Dec 10 '21 at 10:52
Mac OS 10.13.6 (High Sierra): no "Files" under Privacy. – SteveWithamDuplicate Oct 05 '22 at 21:16

score 0 · Answer 9 · answered Sep 18 '17 at 03:42

I realize this is a very old topic but I don't see this thread addressing my symptom so I thought I'd post another opinion.

I had this happen to an external drive that had been functioning perfectly on a Snow Leopard iMac, which got upgraded to El Capitan along the way. Earlier this year, I took that drive and put it in a new Windows 10 box which was running Paragon HFS for Windows. I copied hundreds of GB of files FROM Windows TO HFS+ on that drive and plugged it back into the iMac. Everything worked fine, except one shell script I had that staged files for backup encountered this uchg issue.

In short: files and folders created under El Capitan or Windows 10 using Paragon HFS, when moved back to a Snow Leopard box, the "locked" radio box will NOT be checked when you select Get Info in the Finder. However, others' suggestions worked fine for me:

verify that's the issue by running ls -leO@ (that's a capital oh) on a suspect file
as root, run chflags -R nouchg on the parent directory (there's no -f in Snow Leopard)

It'll work, just don't expect the exact same visual cues if your drive has gone between operating systems or if you use Paragon HFS.

chflags -f -R nouchg directory does work thanks – odjeezeus Jun 04 '18 at 23:00 — odjeezeus, Jun 04 '18 at 23:00

File can't be moved by root on OS X

9 Answers9

Before using arcane commands, confirm your System Preferences