When cargo can't run because it doesn't have permissions to a file, error messages should mention which file is causing the problem

[rask]

I'm running the pre-packaged Windows GNU version of Rust on Windows 7 64-bit. I use Avast Antivirus.

When my antivirus is enabled, I cannot use any other cargo commands but new. All other commands return Access is denied. (os error 5).

After disabling my antivirus' processes, other Cargo commands work fine.

Is this something which could be prevented inside Cargo or is it something that all users should "know" and fix themselves? Is this a known problem?

Building and running exes created with plain rustc worked fine when AV was running, so it is related to something Cargo is doing.

[alexcrichton]

This may just be a case where we need to provide a better error message. Could you gist a full log perhaps? I'd also be curious to figure out which function is actually returning this error...

[rask]

Sometimes this issue prevents running Cargo commands at all, as in the executed Rust application hangs and does not output anything when using cargo run. Ctrl-C breaks the execution though. Running cargo build does nothing (no output) but doesn't hang either.

I can't see documentation on logging anywhere. Any idea where to look for log files or how to debug the execution? Should I clone and build to be able to do any proper debugging? I could not find logs anywhere where applications usually do logs.

[rask]

Strange, I have now disabled my antivirus as much as possible (uninstalling is the only option left right now), and still the Cargo commands result in

> Access is denied. (os error 5)

Running without Cargo works fine:

$ cd target/debug && ./app.exe
> Hello, world!

It seems the antivirus may not be the culprit here. I'll continue investigating.

[alexcrichton]

How are you seeing the Access is denied. (os error 5) error message? Is Cargo printing that? If cargo build works (which it looks like it did if target/debug/app.exe was created), then if you run cargo build --verbose or perhaps cargo run --verbose then the output should appear on stdout.

[rask]

cargo build worked temporarily after juggling AV settings, hence the built exe. Both cargo run --verbose and cargo build --verbose are broken, displaying the os error 5 message. Leaving out --verbose does not print the error message, but instead tells me to use --verbose to get a better error message.

Examples of what I see in my terminal:

$ cargo clean --verbose
> could not remove build directory
>
> Caused by:
>    Access is denied. (os error 5)

$ cargo run --verbose
>     Compiling app v0.1.0 (file:///D:/Projects/Rust/app)
> Access is denied. (os error 5)

$ cargo build --verbose
>     Compiling app v0.1.0 (file:///D:/Projects/Rust/app)
> Access is denied. (os error 5)

$ cargo build
>     Compiling appv0.1.0 (file:///D:/Projects/Rust/app)
> An unknown error occurred
>
> To learn more, run the command again with --verbose.

I found that the os error 5 comes from Windows itself: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx

Cargo is running to some permission wall and uses the Windows error message there.

Most searches I made on that error relate to SQL server running on Windows Server. People have been told to fix it by running the SQL server process itself in elevated mode.

The directory permissions for my project directory matches what I've always used for my whole system. All other tools which have not explicitly stated that elevated permissions are needed have worked fine (e.g. build tools, compilers, software installers, and so on). The above error messages appear on an elevated cmd.exe prompt too, so it is not about the permissions of the terminal trying to run Cargo.

I'll attempt to elevate cargo.exe itself and see if that makes it work.

EDIT:
Changing the cargo.exe and rustc.exe permissions to "Run this program as administrator" makes no other difference, than that non-elevated prompts cannot find the executables anymore. Elevated prompts show the same error messages.

[retep998]

Note that access can also be denied if it tries to open a file which another process currently has a lock on. It's not just about permissions. Sure would be nice if Cargo would tell you what operation it was trying to do which caused that error.

[rask]

Apparently there were four(!) ghost processes that did not want to die until I suffocated explorer.exe. After I managed to get rid of the ghost processes, Cargo commands worked fine after I disabled Avast Antivirus to the brink of uninstallation.

Does Cargo shove processes it cannot "run" to the background for explorer.exe (or the terminal parent process) to handle? Sometimes when a process is tied to explorer.exe it cannot be terminated as is, but the explorer.exe process needs to be rebooted first (Windows stability protection at work).

I think the issue here is the behaviour Cargo does when a Rust program cannot be run properly through cargo run: it releases it to the wild, hence the users themselves have to find out how to end the process properly. Perhaps add a test to verify that Cargo has the permissions to operate on the files and then fail with a more descriptive message in case Cargo does not have the permissions? Is this possible without major modifications to the Cargo logic?

[retep998]

At the very least whenever Cargo tries to access or execute a file, if it errors, it should include the path to the file in the error.

[rask]

Did not see such behaviour in my setup. It either hanged or exited with that os error with no information on what exactly caused the error. Not sure if this relates to me using the pre-built binaries instead of a custom built Cargo binary.

[Restioson]

I believe this can be closed. I get:

error: cannot read "/home/restioson/IdeaProjects/vertex/client/gtk/.flatpak-builder/cache/objects/54/2b14975bb28ba3a0b02b1145c19f9a4ee911e95e586e3b6897687530139e5f.file/containerd"

Caused by:
  Permission denied (os error 13)

Which clearly mentions the file that is causing the problem.

[ehuss]

@Restioson This issue is for some situation on Windows where "Access is denied" is encountered, not "Permission denied". Possibly related to anti-virus. Cargo has dozens (hundreds?) of places where it accesses files, and any one of them could have raised that error without printing the path.

[Restioson]

Ah I see.

[seanvikoren]

Cargo is difficult to use on my system because of this ghost process problem:

Downloaded rayon-core v1.9.0
  Downloaded miniz-sys v0.1.12
  Downloaded png v0.5.2
  Downloaded 21 crates (901.4 KB) in 9.71s
error: The process cannot access the file because it is being used by another process. (os error 32)

c:\dev\ash\examples>cargo run --bin triangle
error: The process cannot access the file because it is being used by another process. (os error 32)

c:\dev\ash\examples>cargo run --bin triangle
error: The process cannot access the file because it is being used by another process. (os error 32)

c:\dev\ash\examples>cargo run triangle
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: texture, triangle

[ehuss]

@seanvikoren Can you run with the RUST_BACKTRACE=1 and CARGO_LOG=trace environment variables set and copy the output?

[sr2ds]

Hello guys,

I just went through this and, if someone has the same problem, it can help:

I use the mongodb database locally running on docker, this action created a directory named data within the structure of my project. For some reason, the cargo watch only came back to work now that I ran a chown on data directory.

Then for diagnostics, check the permissions of the files that are at the same level as your project.

The image below is an example of how it didn't work:

And below, an example of how I made it work:

[ehuss]

I'm going to close this as probably fixed. Extra context was added to error messages in #8232 among other PRs. Otherwise, without additional information on the specific cases reported here, I don't think any progress can be made.

For anyone encountering similar problems, please open a new issue with as much detail as you can provide.

[martinfiscina]

Same problem:
when "cargo run":
error: failed to link or copy C:\Users\Martin\projects\rust\hello-cargo\target\debug\deps\hello_cargo.exe to C:\Users\Martin\projects\rust\hello-cargo\target\debug\hello-cargo.exe

Caused by:
Acceso denegado. (os error 5)