Closed mkw closed 7 years ago
commitay
commented
7 years ago I can reproduce the rm: /var: Operation not permitted error but /var is still a symlink to /private/var after uninstall and reboot.
Edit: Closed by accident.
This seems to be similar to https://github.com/caskroom/homebrew-cask/issues/33006
mkw
commented
7 years ago Doing a little more digging, /var has restricted set, which should make it impossible for normal processes, even those running as root, to modify it:
$ ls -leO@ /var
lrwxr-xr-x@ 1 root wheel restricted,hidden 11 Jun 26 12:13 /var -> private/var
com.apple.FinderInfo 32
com.apple.rootless 0I am not sure why this protection failed me a few weeks ago and my co-worker today. I tested reinstall on my own machine twice today just making this issue, and both times, the rm of /var was properly stopped.
General troubleshooting steps
brew update-reset && brew updateand retried my command.brew doctor, fixed as many issues as possible and retried my command.Description of issue
A few weeks ago, I upgrade Pritunl using
brew cask reinstall pritunland my OS install started acting flaky soon after, so I restarted. My machine failed to boot, and after an hour or two of digging, I gave up and simply reinstalled and got back to normal (thanks to the good folks at Apple, this was surprisingly painless).Today, a new version of the Pritunl cask appeared, and I decided to upgrade. The upgrade worked fine, but I happened to notice
rm: /var: Operation not permitted, so I checked to make sure that/varwas ok. Sure enough, macOS had saved me this time.Unfortunately, a co-worker was not so lucky. He upgraded an hour or so later, had his machine behave weirdly, then rebooted, and it died in the same way the time had a few weeks ago. Fortunately, I remembered the warning from this morning, and had him boot into the recovery OS, mount his normal root partition, and examine the
/varfile. Instead of being a symlink toprivate/varas should be the case in macOS normally, it was a real directory. A few log files and databases had been recreated in their normal locations inside/var, but too much was missing for macOS to boot. He moved the/vardirectory to/var.brokenand did aln -s var private/varin the partition's root. Rebooting then worked normally and his machine is fixed.Not being all that familiar with pkgutil/lsbom, or under what conditions the system would oddly decide to allow even the super-user to delete
/var(I thought that Sierra, or maybe even Yosemite, made that impossible), I am not sure if this is a problem with Cask's use of pkgutil, or with the Pritunl install itself, but if there is anything that pritunl can do to prevent broken uninstall scripts from damaging the system, it would be good, so I'll start here. Feel free to tell me that I should file a bug with Pritunl instead.Output of your command with
--verbose --debugSection of note (that last line is the problem):
Full log:
Output of
brew cask doctor