After upgrading to MacOS Catalina, I have a Relocated Items folder on my Desktop. Inside this folder is a PDF explaining what these items are.

Inside the folder are two sub-folders - Configuration and Security. These folders contain items that were in locations which are no longer compatible with the new macOS configuration. You are advised to review the items in these directories and take appropriate action.

The problem is that within the Security/usr folder is a symbolic link called X11 pointing to /opt/X11. The /opt/X11 directory does not exist and I cannot remove the X11 link with either unlink or rm (as sudo and have tried after sudo su to get a root shell). When I try to remove the file, I get "Operation not permitted". I can move the link to the Trash, but when I do, trying to empty Trash results in an error saying it cannot be emptied because X11 is a file required by macOS. So, how do I get rid of this link?

Update: I also noted that xattr shows nothing.

  • 1
    Hi Tim, please have a read through this article: osxdaily.com/2018/10/09/… Although it is concerted with MacOS Mojave, you will find this should assist you in removing that folder. Also use the sudo rm -rf command to remove that symlink. Oct 9, 2019 at 1:21
  • 2
    @Danijel-JamesW Thanks, but sudo rm -rf doesn't help, just gives the same error.
    – Tim X
    Oct 9, 2019 at 1:41
  • Also verified the terminal app has full disk access, so that is not the issue. Looks like I may need to delve into turning off SIP and see if that works
    – Tim X
    Oct 9, 2019 at 1:52
  • 3
    You do not need to disable SIP, but you do need to boot to the Recovery OS and delete it in Terminal from there, e.g.: rm -r /Volumes/Macintosh\ HD\ -\ Data/Users/[short_user_name]/Desktop/Relocated\ Items Oct 9, 2019 at 2:32
  • 12
    I didn’t feel like venturing to the Recovery OS, so I just sudo mv Relocated\ Items /tmp. Out of sight, out of mind, as they say.
    – Fls'Zen
    Oct 11, 2019 at 0:01

6 Answers 6


As this question has had over 1k views, it seems it is a common issue. Therefore, I thought I would outline what I did to get it resolved in case others find it useful.

When I first tried to remove the link, I was told the operation was not permitted. Looking at the link, I could see it was owned by root and in the wheel group. I therefore then tried to remove it with sudo i.e.

sudo unlink X11

This failed with the same error. I also tried

sudo rm -rf X11

but this also failed with the same error. I then posted here asking for help and @Danijel-JamesW added a comment with a link to a useful article that provided some background on the new security features initially introduced in the previous version of macOS, but extended in Catalina. One of the things this article highlights is that some applications, like terminals and editors (in my case Emacs), need to have the full disk access privilege. Without this privilege, you will often get operation not permitted errors in unexpected locations/situations. Unfortunately, this was not the issue in my case. My terminal app (iTerm2.app) had the necessary permissions. However, the article did indicate that you could also get around the operation not permitted error by disabling SIP (System Integrity Protection). This was going to be my next move. However, in the end, it was not necessary.

Thanks to a comment from @user3439694 I found out that you can boot into Recovery Mode and use the terminal to delete the file. This is what I did:

  1. Boot holding down Cmd+R
  2. Click on Utilities and select Terminal from the top menu
  3. Enter rm -rf /path/to/file/to/remove
  4. Reboot

This solved my issue. One important thing to note is that working in the recovery terminal is powerful and potentially dangerous. You need to make sure you are deleting what you mean to delete. To be extra safe, instead of immediately issuing the rm command, you can use ls -l to make sure you have the correct file or directory and then hit the up arrow to bring back the command from the history, move to the beginning of the line, remove the ls -l and type rm -rf, leaving the path unmodified following the rm -rf. Note also that the -r means recursive and -f means force - very powerful and dangerous. It will essentially remove everything from the point specified in the path downwards i.e. all sub-directories and files. So, if you get that path wrong, you may end up deleting much more than you expected. In my case, the path I needed was:

/Volumes/Macintosh\ HD\ -\ Data/Users/tim/Desktop/Relocated\ Items

My login account is tim. The \ are needed to escape the spaces in the path. Most systems will have the path starting with /Volumes, but the drive name may differ (i.e. Macintosh HD). The - Data is fairly standard.

Anyway, this fixed the issue, and those irritating files are now gone and my Desktop folder is clean (for now!).

  • 5
    After booting into Recovery Mode, the data volume wasn't available in /Volumes. I had to open Disk Utility and explicitly mount it (took a while to prompt for a password) before being able to cd into it and delete the file.
    – David Lord
    Oct 27, 2019 at 0:30
  • Also, if you already moved the folder to the bin, it'll be in .Trash in your user folder rather than eg Desktop.
    – David Lord
    Oct 27, 2019 at 0:31
  • 1
    Guessing it might be from disk encryption on my simple MBP setup (with a single disk). The - Data volume seems to be part of the System and Data volume separation in Catalina, but dunno why it auto-mounts on some systems but not others. Hey, at least it still all works ¯\_(ツ)_/¯
    – David Lord
    Oct 29, 2019 at 4:50
  • 1
    Had a similar experience to @DavidLord's. My Macintosh HD - Data volume was not available in the Recovery Mode terminal and I had to manually mount it in Disk Utility. In order to do that it asked me for a user password, because the volume was encrypted with File Vault. Maybe that would explain why it didn't get mounted automatically.
    – tompave
    Apr 11, 2020 at 22:46
  • 2
    After getting into Recovery Mode, I removed it with unlink X11. No need to type rm, and certainly not -rf, for just this symlink. The rest of the directory tree you can handle in normal user mode.
    – duozmo
    Jan 23, 2021 at 3:15

I used the procedure found at MacReports.com:

  • boot into Recovery Mode,
  • disable csrutil,
  • reboot,
  • delete the folder (in either the Finder or Terminal),
  • reboot into Recovery Mode,
  • re-enable csrutil; and,
  • reboot.

Four reboots (!), yes -- but so far, so good.


Tim X's solution worked for me. The tl;dr is

  1. Recovery mode: command + R
  2. Utilities -> Terminal
  3. rm -r /path/to/file/or/dir/to/remove (The -r alone worked for me -- Tim used rm -rf force mode)
  4. Reboot

The issue is caused by X11 symlink which is setup by XQuartz and this points to X11 folder which is protected by Mac OSX. At some point you might have installed XQuartz and the original procedure is to uninstall XQuartz and reinstall XQuartz after Catalina upgrade.

In my case, I had installed XQuartz via homebrew cask and had already upgraded to catalina. So firstly, uninstall XQuartz.

$ brew cask ls
$ brew cask remove xquartz
  • now restart your mac
  • hold "cmd + r" (you can release the keys after a few seconds just after apple logo appears with the progress bar)
  • now you are in recovery mode
  • select from the top menu utilities > terminal
  • enter the following to disable apple secure integrity
$ csrutil disable       # this disables apple secure integrity tool 
  • close the terminal
  • select from the top menu restart and wait for normal boot into your account
  • now you can delete the files which are stuck and bin them as usual
  • for completness, reboot into the recovery mode as above steps and in the terminal enter
$ csrutil enable       # this reenables apple secure integrity tool
  • restart and login as usual

if you are freaking out as you are being warned of deleting/binning a protected folder, you can opt to use "unlink X11" command instead to remove the symlink. this worked for me and hope it helps.

to understand or test the issue you can try the following which in the case of trying to disable system integrity results in an error

$ csrutil status
System Integrity Protection status: enabled.
$ csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
  • Fairly sure I've never installed XQuartz, so it is likely this is another possible cause. Did consider installing it in order to us x2go, but found I didn't need it, so didn't do it. Do have a number of other homebrew apps and this mbp is near end of life, so has had a number of OSX upgrades. Suspect it was from an old OSX or some other homebrew recipe.
    – Tim X
    May 8, 2020 at 23:36
  • That might be possible as well. Similarly I have upgraded OSX from eons ago and it might be other dependancies or apps. The cause is similar which is a symlink that cannot be removed due to the system integrity protection. This kicked in fairly recently and sort of froze anything before to be system default. May 9, 2020 at 15:23

I personally don't like to turn off SIP/security features, if I can help it.

The way I do this is as follows:

  1. Reboot and immediately hold down cmd+r (booting into recovery mode)
  2. Open Disk Utility (you likely have to select your admin user and login first)
  3. Mount your data volume (e.g. Macintosh HD - Data)
  4. Quit Disk Utility
  5. In the toolbar, open Terminal (Utilities->Terminal)
  6. rm -rf /Volumes/Macintosh\ HD\ -\ Data/Users/[your-user]/[path-to-relocated-items]
  7. reboot

You should not have to disable SIP/csrutil.


Having struggled with all the advice, and sudos, suddenly I had this idea....: what if...? And yes! I just moved everything from the Trash bin to my Dropbox folder (which apparently was allowed, nothing protested) and subsequently deleted the whole bunch of stubborn files via Dropbox' online interface. And they were gone! Have a nice day, Paul

You must log in to answer this question.

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