I’ve been tracking a strange issue on macOS 10.15.1 since yesterday. Two people were having a problem installing Malwarebytes, and an error like the following was found in the install.log on both systems:
2019-11-01 13:14:19-06 some-imac Installer[606]: install:didFailWithError:Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory" UserInfo={NSFilePath=/private/tmp/PKInstallSandbox.XXXXXX}
While investigating, both I and a Malwarebytes support engineer both independently found the same thing on these two systems: the /private/tmp folder had been replaced with a recursive symlink, pointing back to itself. And, worse, that symlink was marked with a restricted flag, meaning that it was protected against being modified by System Integrity Protection. 😱
% ls -alO /private/tmp lrwxr-xr-x@ 1 root wheel restricted,hidden 11 Sep 29 2018 tmp -> private/tmp
This apparently prevents the Malwarebytes installer from working, and I’d guess (although I haven’t been able to test) that this means any installer .pkg will fail.
How to fix the problem
Testing has been difficult, as it appears to be impossible to add a restricted flag to the symlink in recovery mode. Which means I’ve been unable to duplicate the exact conditions, and so I cannot be 100% sure of the ideal fix.
In theory, one should be able to fix this by rebooting in recovery mode, opening the Terminal, and executing the following commands:
cd /Volumes/"Macintosh HD - Data"/private rm -rf tmp mkdir -m 777 tmp
(Note that you will need to replace “Macintosh HD” with the name of your hard drive.)
While in recovery mode, you should be able to freely delete items with a restricted flag, and you will have root permissions by default. You do have to be careful to identify the correct /private/tmp, however, as there are two. If you specify /private/tmp, that refers to a folder on the read-only system volume, which is (of course) read-only. You must make the necessary changes to the one on the Data volume.
In the two cases we observed, the fix was more extreme. In one case, the system was wiped and restored from Time Machine. In the other, SIP was disabled, the tmp folder was fixed while booted normally, and then SIP was re-enabled. So, if the above instructions don’t work, these are two verified methods that should work.
How did this happen?
That’s an excellent question! I’m still not sure. I’m guessing this is an obscure Catalina bug, but that’s still speculation.
There’s one thing the two affected systems had in common: both had installed 10.15.1 via recovery mode, and both had done a restore from Time Machine.
In one case, the user had installed 10.15.1 first, then restored data onto it from Time Machine. In the other, the user had restored the system from Time Machine, and then, due to problems and with the help of Apple support, installed 10.15.1 over that system via recovery mode.