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?

  • 1
    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 9 '13 at 19:10
  • 1
    @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 9 '13 at 19:13
  • Welcome to Ask Different! I'll remove the edits and make this a question and leave the answer for the answer section... – bmike Sep 9 '13 at 20:25

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

|improve this answer|||||
  • 1
    Ha! It looks like you answered your own question just as I was posting this answer! – binarybob Sep 9 '13 at 19:27

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.

|improve this answer|||||
  • 1
    What does the csr in csrutil stand for? – Michael Terry Jul 9 '16 at 18:32
  • 13
    I believe it was Benjamin Franklin who said "Those who sacrifice ease of use for security deserver neither". Or something. – dgig Jul 21 '16 at 15:02


chflags -f -R nouchg directory

on a higher level directory to stop this problem.

|improve this answer|||||
  • 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 4 '17 at 16:27

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

$ sudo ls -leO@ foo@example.com/Documents/.%cb_defense/cb.doc
-rw-rw-rw-  1 root  wheel  - 41984  1 Mar 11:20 foo@example.com/Documents/.%cb_defense/cb.doc

$ sudo rm -rf foo@example.com/Documents/.%cb_defense/cb.doc
rm: foo@example.com/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.

|improve this answer|||||

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.

|improve this answer|||||

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.

|improve this answer|||||
  • chflags -f -R nouchg directory does work thanks – odjeezeus Jun 4 '18 at 23:00

You must log in to answer this question.

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