Fix R Package Install Errors: 00LOCK and Exit Status

"Installation of package had non-zero exit status" is a summary, not a cause. Scroll up to the first line that starts with ERROR. It almost always points to one of five problems: a leftover 00LOCK folder, a package name or repository R cannot find, a source build missing a compiler or system library, a library you cannot write to, or a dependency that failed first.

Each error below was reproduced on macOS with the CRAN build of R 4.5.1 on Apple silicon, installing into temporary libraries so that no real library was changed. Library paths in the output are shortened to /path/to/library. The Windows and Linux advice was checked against R and Posit documentation but not executed for this guide.

Collect four facts before changing anything

Run this in the same R session, or the same RStudio or Positron console, where the install failed:

R.version.string        # which R is installing
.libPaths()             # where packages go; the first path is the default
getOption("repos")      # where packages come from
getOption("pkgType")    # "source", "binary", or "both"

Read the answers before trying fixes:

• R version. Binary packages are built for a specific R minor version, such as 4.5. A very new or very old R can turn a quick binary install into a source build, or make a package unavailable.
• Library path. If the first path is inside a synced folder such as OneDrive, or a system folder you cannot write to, expect lock and permission errors.
• Repository. @CRAN@ means no mirror is set. In a script run with Rscript, install.packages() then stops with trying to use CRAN without setting a mirror.
• Package type. "source" means every package with compiled code is built on your machine. That is normal on Linux, and also on macOS if R was installed through Homebrew rather than from CRAN. CRAN's macOS and Windows builds of R default to "both", which uses binaries when available.

When a script needs a repository, set it explicitly at the top rather than relying on a mirror chosen interactively:

options(repos = c(CRAN = "https://cloud.r-project.org"))

Find the first error, not the last warning

One failure can produce a chain of messages. This test installed three packages from source, where quantities depends on units and units needs a system library that was not installed. The end of the log read:

ERROR: configuration failed for package ‘units’
* removing ‘/path/to/library/units’
ERROR: dependency ‘units’ is not available for package ‘quantities’
Perhaps try a variation of:
install.packages('units')
* removing ‘/path/to/library/quantities’

The downloaded source packages are in
	‘/path/to/downloaded_packages’
Warning messages:
1: In install.packages(c("errors", "units", "quantities"), lib = lib,  :
  installation of package ‘units’ had non-zero exit status
2: In install.packages(c("errors", "units", "quantities"), lib = lib,  :
  installation of package ‘quantities’ had non-zero exit status

The last lines blame quantities, but nothing is wrong with it. The first ERROR is about units, and fixing that fixes both. In RStudio or Positron, copy the whole console output into a text editor and search for ERROR from the top.

Clear a 00LOCK folder safely

While installing from source, R creates a folder named 00LOCK- followed by the package name inside the library, so two installs cannot change the same package at once. If R crashes, the session is killed, or the computer sleeps during an install, the folder can be left behind, and every later source install of that package into that library fails:

ERROR: failed to lock directory ‘/path/to/library’ for modifying
Try removing ‘/path/to/library/00LOCK-praise’
...
Warning message:
In install.packages("praise", type = "source") :
  installation of package ‘praise’ had non-zero exit status

First, make sure no other R session, background job, or terminal is installing packages; in that case the lock is doing its job. Then remove exactly the folder named in the message, and nothing else:

lock <- file.path(.libPaths()[1], "00LOCK-praise")  # use the path from your error
dir.exists(lock)                                    # TRUE: the stale lock is there
unlink(lock, recursive = TRUE)
dir.exists(lock)                                    # FALSE: removed
install.packages("praise")

In the test, the source install failed while the lock existed and succeeded immediately after the folder was removed. A binary install on macOS did not check the stale folder, because binary installs only lock when the install.lock option is set, so a lock problem can seem to come and go depending on which kind of install R chooses. Remove the stale folder anyway; the next source install will hit it. If the message names a different library from .libPaths()[1], use the path from the message. If a lock reappears every time on Windows, check whether the library is in a OneDrive-synced folder or being scanned by antivirus software while R writes to it; moving the library to a local, unsynced folder is the durable fix.

Fix "not available for this version of R"

This message means R could not find the package in any repository in getOption("repos") for your R version and platform:

package ‘notARealPackage123’ is not available for this version of R

A version of this package for your version of R might be available elsewhere,
see the ideas at
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages

Despite the wording, the R version is rarely the cause. Check these in order:

1. Spelling and capitalization. Package names are case-sensitive: "Ggplot2" %in% rownames(available.packages()) returned FALSE, while "ggplot2" returned TRUE. To find the right capitalization, search the list with grep("^ggplot2$", rownames(available.packages()), ignore.case = TRUE, value = TRUE).
2. The repository. Many bioinformatics packages are on Bioconductor, not CRAN. Install those with BiocManager::install("PackageName") after installing BiocManager from CRAN.
3. Archived from CRAN. Open https://CRAN.R-project.org/package=PackageName. If the page says the package was archived, it no longer has current binaries, and installing an old version means building from source. Look for a maintained replacement before reaching for the archive.
4. Not on a repository at all. Some packages are only on GitHub. Install those deliberately, with a tool such as remotes or pak, from a source you trust.
5. A genuinely newer R requirement. The package's CRAN page lists Depends: R (>= …). If your R is older, upgrade R rather than forcing an old package version.

Fix source builds: use a binary or install what the build needs

Packages with C, C++, or Fortran code must be compiled when installed from source. That needs a compiler and, for many packages, a system library. Here is the reproduced units failure, trimmed to the important lines:

* installing *source* package ‘units’ ...
checking for udunits2.h... no
checking for udunits2/udunits2.h... no
checking for ut_read_xml in -ludunits2... no
  Configuration failed because libudunits2.so was not found. Try installing:
    * deb: libudunits2-dev (Debian, Ubuntu, ...)
    * rpm: udunits2-devel (Fedora, EPEL, ...)
    * brew: udunits (OSX)
ERROR: configuration failed for package ‘units’

You have two good fixes.

Fix 1: install a binary instead

On macOS and Windows with CRAN's R, a prebuilt binary avoids compiling entirely. In the same R session, install.packages("units", type = "binary") installed and loaded units with no system library installed.

Binaries usually reach CRAN a little after the matching source release. When a newer source version exists, an interactive session can ask whether to install from source the packages that need compilation. Answering No installs the slightly older binary, which is almost always the better choice for analysis work. Answer Yes only if you need the newest version and have the build tools.

On Linux, CRAN does not provide binaries, so every install.packages() call builds from source by default. Two practical options are your distribution's prebuilt R packages, where available, and the Linux binaries from Posit Public Package Manager. Its setup page generates the exact repository URL and any extra settings for your distribution and release; copy them from there rather than guessing the URL.

Fix 2: install the tools and system library the build names

When you need a source build, the configure message usually tells you what to install. For units, that is sudo apt install libudunits2-dev on Debian or Ubuntu, sudo dnf install udunits2-devel on Fedora, or brew install udunits on macOS. Install it, then retry the R package. Other common examples are cmake for nloptr and GDAL, GEOS, and PROJ development packages for sf.

The compiler itself is platform-specific:

• Windows: install the version of Rtools that matches your R version. An Rtools release for a different R version will not be used.
• macOS: install Xcode Command Line Tools with xcode-select --install. CRAN also documents additional tools for some packages, such as a Fortran compiler, on its macOS tools page.
• Linux: install your distribution's build tools, such as build-essential on Debian and Ubuntu, plus the R development headers if your R came from distribution packages.

If you installed R on macOS with Homebrew and every package is compiling, that is expected: CRAN's macOS binaries are built for CRAN's R. Installing R from CRAN's macOS installer is usually the fastest way to binary installs.

Fix library permissions and packages in use

If R says the library is not writable and offers a personal library, it is trying to install into a system location you do not own. Accepting the personal library is the usual fix for a single-user machine. Do not run R as an administrator, or with sudo, just to install packages into the system library; that mixes package ownership and causes the same problem later.

To check whether R can write to the library it will use, run file.access(.libPaths()[1], 2) == 0. TRUE means writable.

If R reports that it cannot remove prior installation, or Windows reports a file in use, the package is loaded somewhere. Close other R sessions, stop RStudio or Positron background jobs, restart R, and install before loading any packages. Unloading packages covers why a restart is more reliable than detaching.

Restore an renv project on a new machine

In a project that uses renv, renv::restore() installs the exact versions recorded in renv.lock. On a new machine or a newer R version, binaries for those exact versions may not exist, so restore falls back to source builds and hits the errors above. Read the first error the same way, then choose deliberately:

• Install the missing build tool or system library and run renv::restore() again, keeping the recorded versions.
• Or, if the team agrees to move a package forward, install a current version with renv::install("units"), test the project, and record it with renv::snapshot() so everyone gets the same change.

renv::status() shows where the library and lockfile disagree. Do not delete renv.lock to make an error go away; it is the record of which versions produced your results.

A clean retry sequence

1. Restart R, so no packages are loaded.
2. Run the four checks from the first section and fix an unset repository or a surprising library path.
3. Install one package, and read its log from the first ERROR.
4. Remove only a stale 00LOCK folder named in the error, after confirming nothing else is installing.
5. Prefer a binary. If you need a source build, install the system library or compiler the message names.
6. After it installs, run library(pkg) in a fresh session to confirm it loads.

If you are cleaning up after many failed attempts, uninstalling a package from the right library explains how to remove partial installs without touching other packages.

FAQ

Is it safe to delete every 00LOCK folder in my library?

Only when no install is running anywhere on the machine. A lock belonging to an install in progress protects that install. Removing just the folder named in the error, after closing other sessions, is the safer habit.

Why does the same package install on Windows but fail on Linux?

On Windows, CRAN's R normally installs a prebuilt binary. On Linux, it builds from source by default, which needs a compiler and every system library the package uses. Use Linux binaries from a package manager, or install the system libraries named in the configure output.

The install worked but R warns that the package was built under a newer R version. Is that a problem?

Usually not. In the test, the units binary for R 4.5 printed package ‘units’ was built under R version 4.5.2 on R 4.5.1 and loaded and worked normally. The warning is informational within the same minor version. Updating R to the latest patch release removes it.