MacOS Catalina creates “Relocated Items” on every update

catalinasetup-assistant

I am running two new Mac's that both were delivered in 2020 with macOS 10.15 Catalina installed (2017 iMac Pro delivered in 2020 and the new 2020 MacBook Air).

On update from 10.15.4 -> 10.15.5 both of these Macs created Relocated Items and wiped out my the contents of my /etc and /var directories.

  • My understanding is that this behavior is not expected for Catalina -> Catalina updates. The documentation on Relocated Items seems to apply mostly to Mojave -> Catalina.

On the iMac Pro, I was also redirected to the full setup procedure because /var/db/.AppleSetupDone was moved. This was also moved on the MacBook Air, so I'm not sure why I didn't see it there as well.

My conjecture is that this has to do with my use of synthetic.conf to create a link from /p that points to /Volumes. This is to map directories between system when I connect to a smb drive on a linux computer. But I can't see why this would cause any issues as it is supported mechanism.

  • Why I think this may be related. The relocated items show in the directory: /Users/Shared/Relocated Items/Security/System/Volumes/Data/rivate which seems like a misspelling of "private" without the "p", which is my only clue. (Although, this seems like it would indicate something surprisingly sloppy in the coding…)
  • Also /Volumes/System/Data/private contains etc and var which are precisely the folders that are causing me problems.

Other software that is impacted includes MacTex 2020 (which installs its paths in /etc). This also wipes out all the printers I install (because they put stuff into /etc as well).

Possibly related…

I ran the permissions to see if this has any impact on my next update.

Any ideas would be helpful!

Best Answer

  • I also experienced this problem over several Catalina and Big Sur updates.
  • I too had a /p link defined in /etc/synthetic.conf
  • I too noticed the rivate misspelling.

So before updating to macOS 11.4 today, I rebooted in recovery mode and removed my synthetic.conf. The update then installed normally, without blowing away my /var and /etc directories and without running the new installation setup. I conclude that having a /p link does cause this problem.