Windows artifact issue - "access denied" when installing Plots/Makie

For a few days now I’ve been unable to precompile Plots and CairoMakie on my Windows machine due to “access denied” errors with artifacts. Here’s that I see:

Precompiling project...
  ✗ Cairo_jll
  ✗ HarfBuzz_jll
  ✗ libass_jll
  ✗ FFMPEG_jll
  ✗ GR_jll
  ✗ Plots
  ✗ Plots → UnitfulExt
  118 dependencies successfully precompiled in 150 seconds. 13 already precompiled.
  8 dependencies errored. To see a full report either run `import Pkg; Pkg.precompile()` or load the packages
  1 dependency had warnings during precompilation:
┌ GR [28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71]
│  ERROR: LoadError: InitError: could not load library "C:\Users\ngudat\.julia\artifacts\3628616b5a5a8fd8628079ae4fb0d8948fdb37bc\bin\liblzo2-2.dll"
│  Access is denied.

The exact artifact sometimes changes, but all artifacts are in the same folder and many of them can be successfully used. I can precompile everything when I start Julia in an admin-elevated shell, but then I can only use the packages as an admin so that’s not really a solution.

I’ve gone into the Windows file permission menu which showed my user account as having read access to the files, and I’ve also given myself full permissions on the relevant dlls to no avail.

Has anyone come across this?

I’ve seen this error in the past with libraries that weren’t marked as executables, but that isn’t the case for LZO_jll v2.10.1+0, so I don’t think that’s the problem here (also because you said this happens with various artifacts, so the problems seems widespread). But somehow julia can’t load the downloaded library.

…and just like that the problem disappeared. I gave myself full access to the file (which worked without admin rights as the artifacts are in my user folder anyway), restarted the computer and precompilation went through. Somewhat unsatisfactory solution but at least I can plot again!

Another update, the same issue - this time it was OpenSSL, which initially complained about libcrypto-3-x64.dll and then libssl-3-x64.dll. The way I solved it this time was to give EVERYONE full permissions to the files, then reboot. Sometimes the permissions didn’t stick though so I had to re-assign them after booting, but the key was to do it before trying to precompile - if I tried precompiling prior to changing permissions, precompiling afterwards with new permissions would still fail.

What version of Julia are you using? CC: @visr

Since I started using 1.10.0-beta2 as my daily driver I sporadically run into the same issue, but nothing I can reproduce. If I delete the read-only artifact and add it again, it works.

For instance, this just happened randomly with LibPQ_jll: [GDAL] fix version_offset by visr · Pull Request #7412 · JuliaPackaging/Yggdrasil (, where all files in the artifact were suddenly mode: 0o100444 (-r--r--r--) instead of mode: 0o100666 (-rw-rw-rw-).

julia> versioninfo()
Julia Version 1.10.0-beta2
Commit a468aa198d (2023-08-17 06:27 UTC)
Build Info:
  Official release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 24 × 12th Gen Intel(R) Core(TM) i7-12800HX
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, alderlake)
  Threads: 23 on 24 virtual cores

I was using 1.10beta2 when this issue first appeared. I then tried to isolate it to that version but interestingly after I saw the error on 1.10beta2 it also popped up on 1.9.3.

Do you mean 1.9.3 installed an artifact with read-only permissions? Or was it just that it errored on trying to use a read-only artifact that 1.10.0-beta2 put there? Because the latter I see as well, but that doesn’t mean 1.9.3 has this issue.

Would you mind to open an issue in Julia? It sounds like there’s a problem with installation of artifacts in v1.10, although the fact that it can’t be consistently reproduced is annoying.

I’m not sure to be honest, but I assume it is the second, ie precompilation failed in 1.9.3 because it was trying to use the artifact that 1.10beta2 installed.