The directory exists, I can reproduce the error by running cargo-make as the gitlab-runner user inside the directory itself.

The directory and all its parent dirs are owned by that user.

The first time this error happened was on my gitlab-runner user during a build, but it has happened once to my normal user yesterday.

This is a transient error, but consistently happens once it has happened (it goes away when I restart my computer, for example, but somehow comes back later).

Writing a trivial program that calls std::env::current_dir() and printing it, during the time the error can be reproduced, works.

This happened when cargo-make has been compiled with stable (1.24.1) or nightly-2018-03-16-x86_64-unknown-linux-gnu. The issue also still happens when the active toolchain is switched to stable or the latest nightly (nightly-2018-03-19), which suggests the issue is neither: which version of Rust was used to compile cargo-make, or the active toolchain.

I can’t tell where along this stack the problem lies, so it’s hard to choose where to raise an issue:

Thanks to @zomerfaun on the rust-lang/rust gitter chat, traced it (literally, straced) it to cargo-make using a common directory in /tmp (which it subsequently did not delete); not the current_dir() call that I thought it was failing on.

Since /tmp has the sticky bit set, and my user and the CI runner are on the same machine, whoever ran the tool first had permissions to the directory.