Permission denied @ apply2files

brew cleanup
Error: Permission denied @ apply2files - /usr/local/share/ghostscript/9.23/Resource/Font/wasy10.pfb

This error appears on every brew update, may since mactex was recently updated.

What to do?

Another tool over wrote a part of your homebrew install and set it to root permission. All you can do is set your own user to be the owner again.

1 Like

Actually the Font that it complaining about is a link owned by my user account. a lot of other fonts are owned by root. The files in /usr/local/share/ghostscript/9.23/Resource/Font/ are all links to TeX fonts in /Library/TeX/Root/texmf-dist/fonts/type1/public, owned by root. It seems this is related to the update by mactex.

/usr/local/share/ghostscript/9.23/Resource/Font/wasy10.pfb points to /Library/TeX/Root/texmf-dist/fonts/type1/public/wasy2-ps/wasy10.pfb, however, the folder wasy2-ps does not exist. Instead there is wasy-type1 where the wasy fonts live.

This fixed he problem (in /Library/TeX/Root/texmf-dist/fonts/type1/public/):
sudo ln -s wasy2-ps wasy-type1

Never before did I have to resort to such a “fix”. I don’t like that.

This is the risk of mixing homebrew (ghostscript) and non-homebrew (mactex) installs. If something changes the owner to root on a homebrew directory it’ll break (since homebrew refuses to run things as root for security reasons)

I’ve just found this after having the same error.

Note that it’s not a permission error - it has nothing to do with the owner being root.

The error is because the symbolic links that homebrew is trying to delete are stale and don’t point to actual files. The fix is to create another symbolic link (yes, as root, but that’s because it’s within the TeX distribution) inside TeX to the folder that used to exist, so that homebrew can clean its link files (in /usr/local…, and still owned by the user not by root). After that, I can delete the link I created as root and everything works again.

The problem as far as I can tell is that homebrew refuses to delete its own /usr/local/… files if they are symbolic links to a file that doesn’t exist. It’s not unreasonable for TeX to shift its files around, so hence it doesn’t strike me as unreasonable that stale symbolic links might occur within a brew package?

Anyway I think that’s what the problem is - let me know if I’ve misunderstood though.

And thanks for Homebrew which is awesome and makes macOS life bearable :slight_smile:

@lyndondrake That’s an interesting take. What would you suggest to the end user doing in that case then?

I run into a similar error after installing graphviz (and I use TeXLive on the latest macOS, so maybe I’m running into the problem you described here).

Error: Permission denied @ apply2files - /usr/local/share/ghostscript/9.27/Resource/Font/wasy10.pfb

1 Like

This is the risk of mixing homebrew (ghostscript) and non-homebrew (mactex) installs.

I don’t think so. Both were installed using homebrew.

Yeah, I wasn’t clear in my naming. By homebrew and non-homebrew I meant packages that are or aren’t build from source by homebrew.

Would you be able to give me dumbed down instructions to do that and fix this problem?

Look at my hotfix further upwards…

Out of curiosity, what does ls -ld /usr/local/share/ghostscript/9.23/Resource/Font/ output? I’m guessing you’ll see that it’s owned and writable only by root, and since it’s not part of the ghostscript formula installation, it’s almost certainly created by the MacTeX installer.

If I’m right, that’s the real issue you’re facing: Because the directory is owned by root, you can’t delete any of its contents as yourself, even the files and links that are actually owned by you.

There’s another issue that hasn’t been mentioned yet: The current cask tells the MacTeX installer to not install its own Ghostscript, so the installer hunts for an existing GS installation and drops its GS-related files in said installation (with the wrong ownerships, from what you’ve described). The path that it uses seems to be version-locked, so when the inevitable GS version bump comes along, a brew upgrade would break the existing MacTeX installation, by at least “disappearing” the Resource directory that it expects, and potentially making MacTeX’s cached path to GS itself out of date.

If all that’s true, it would seem that using MacTeX’s own GS installation might actually be the expedient thing to do.

I don’t use MacTeX myself, so perhaps someone who actually uses it could brew cask edit mactex and make the necessary adjustments for it to install and use its own Ghostscript, then test to see if there are any issues and open a PR to make the change permanent? From a quick glance, at least the following changes are required:

  1. Remove depends_on formula: "ghostscript"
  2. In pkg "mactex-#{version.no_dots}.pkg", set all attributeSettings to 1 (i.e. force install of both GS and libgs)
  3. In uninstall pkgutil, add "org.tug.mactex.ghostscript9.50" and "org.tug.mactex.ghostscript9.50libgs" (i.e. ensure uninstall of both GS and libgs)