1

This is on MacOS Catalina, but the same behavior has been observed in prior versions of MacOS.

Similar questions have been asked for other default directories in the default home directory, but this is different. I am able to delete most of the other directories: ~/Music, ~/Public, and ~/Movies all went away after I removed any ACL's from them. But ~/Pictures is different, and no matter what I do, MacOS refuses to delete it.

bash-5.0# /bin/ls -led Pictures
drwxrwxr-x  2 MyLogin  MyGroup  64 Nov  5 18:17 Pictures
bash-5.0# /bin/ls -lea Pictures
total 0
drwxrwxr-x   2 MyLogin  MyGroup    64 Nov  5 18:17 .
drwxr-xr-x+ 72 MyLogin  MyGroup  2304 Nov  5 18:17 ..
 0: group:everyone deny delete

Note that the last ACL is applied to the parent directory of ~/Pictures ie. my home directory, and that is not the cause of this behavior as I am able to delete other subdirectories without trouble.

This also does not appear to be a restriction imposed by System Integrity Protection:

bash-5.0# /bin/ls -leOd /usr/bin
drwxr-xr-x  1014 root  wheel  restricted 32448 Oct 23 01:19 /usr/bin
bash-5.0# /bin/ls -leOd Pictures/
drwxrwxr-x  2 MyLogin  MyGroup  - 64 Nov  5 18:23 Pictures/
bash-5.0# /bin/ls -leOa Pictures/
total 0
drwxrwxr-x   2 MyLogin  MyGroup  -   64 Nov  5 18:23 .
drwxr-xr-x+ 72 MyLogin  MyGroup  - 2304 Nov  5 18:23 ..
 0: group:everyone deny delete

Note the restricted attribute on /usr/bin which is protected by SIP. ~/Pictures has no such attribute.

I've tried as root, as my normal user account, and even as a different user after setting the permission 777. Nothing works.

My question is: what is protecting ~/Pictures from deletion, and how can I turn it off?

Improve this question
14
  • 1
    Not to be flip but macOS is protecting it. you update macOS and it (and most of the others) will all come back. Apple has decreed (gah...) that certain userland directories Shall Not Be Deleted. Which brings to mind "tilting at windmills" or "you can't fight city hall." – Steve Chambers Nov 6 '20 at 0:42
  • @SteveChambers clearly macOS is protecting it. I actually set up a cron job to keep deleting them if they come back, and which runs much more often than the re-spawn (I just hate them that much). So one might say i have vanquished the windmills and stuck it to city hall for 3 out of 4 tries, but this last one is a real pest. – Z4-tier Nov 6 '20 at 0:49
  • @Z4-tier Have you tried with SIP disabled? I know you say it doesn't look like it's protected by SIP, but it also doesn't look like there's anything else preventing its deletion, and yet here we are. Worth a try! – Wowfunhappy Nov 6 '20 at 1:07
  • You can delete it while in macOS Recovery, without disabling SIP. – user3439894 Nov 6 '20 at 1:26
  • @Wowfunhappy, it is protected by SIP, however, as is already said, it can be deleted while in macOS Recovery without disabling SIP. – user3439894 Nov 6 '20 at 1:35
1

My question is: what is protecting ~/Pictures from deletion, and how can I turn it off?

In macOS Catalina the Users > $USER > Pictures folder, aside from ACL's set on it, it is being protected by System Integrity Protection (SIP).

Even using sudo chmod -N Pictures, while in the Home directory in Terminal, the directory can not be deleted unless done from macOS Recovery using Terminal without turning off SIP.

  • Caution: This will remove the Pictures directory and everything in it!

Example:

rm -r "/Volumes/Macintosh HD - Data/Users/name/Pictures"
  • Replacing name in /name/ with your short name, the name of your Home directory.
  • Replacing Macintosh HD as appropriate if you've modified the default name.

If you want to be able to delete if from a normal running occurrence of macOS Catalina, not macOS Recovery, then you will need to turn off SIP from macOS Recovery using Terminal from the Utilities menu.

csrutil disable

You could then immediately use:

csrutil enable --without fs

This way, except for the filesystem, the other protections offered by SIP are still in play.

Personally, I do not recommend doing this and would opt for deleting it from macOS Recovery without turning off SIP and then once booted back to normal mode macOS Catalina... I'd create the directory from Terminal while setting it hidden with SetFile, applying ACL's to prevent any modifications while also removing all normal privileges (rwx), all in the hope that Apple doesn't mess with it until the next upgrade.

That said, if your are the type that always shows all files including the hidden ones, then what's mentioned in the paragraph above is a moot point.

Notes:

To boot to macOS Recovery from a running occurrence, normal mode boot, of macOS, you can use the following compound command from Terminal:

sudo nvram "recovery-boot-mode=unused"; sleep 2; sudo reboot

Then before rebooting from macOS Recovery, in Terminal from the Utilities menu, run:

nvram -d recovery-boot-mode

The latter is not necessary in some versions of macOS, however, it doesn't hurt either way.

Improve this answer
5
  • But shouldn't ls -lO (two bad letters: lowercase "Lima", uppercase "Oscar") show this directory as Restricted the same as /usr/bin? My understanding is that the restricted flag indicates that SIP file system protection is enabled for that path, but maybe I am wrong about that? – Z4-tier Nov 6 '20 at 15:17
  • @Z4-tier, One would think so, however, the only way I was able to delete it was from macOS Recovery without disabling SIP or from a normal mode boot after disabling SIP. So what I've presented does indeed answer the question asked and quoted in my answer. – user3439894 Nov 6 '20 at 15:20
  • Let me give it a try and see if it works, and if so then I will accept this answer and open a follow-up asking about the "Restricted" attribute, what it actually means (apparently not what I assumed, and what I would expect most people would also assume). What is even more bizarre, I can't chown any of the contents of /usr/bin even as root (presumably due to SIP), but ~/Pictures has no such restrictions... – Z4-tier Nov 6 '20 at 15:29
  • @Z4-tier, /usr/bin in macOS Catalina is on a read-only volume and why, from a normal mode boot it cannot be modified without both disabling SIP and remounting / as read-write. – user3439894 Nov 6 '20 at 15:34
  • Ohh yes, I forgot about Apple's latest nanny security scheme with these being mounted read-only. That makes sense. – Z4-tier Nov 6 '20 at 15:54

You must log in to answer this question.

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