Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo fails to create any project on systems with an automounter #15327

Open
samfux84 opened this issue Mar 19, 2025 · 5 comments
Open

Cargo fails to create any project on systems with an automounter #15327

samfux84 opened this issue Mar 19, 2025 · 5 comments
Labels
A-workspaces Area: workspaces C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@samfux84
Copy link

samfux84 commented Mar 19, 2025

Problem

Hi,

On our universities HPC cluster (with 4000+ users), the home directories are mounted via an automounter script in the path /cluster/home/$USER, which basically makes rust unusable:

sfux@eu-login-40:~$ module load stack/2024-06 rust/1.85.0
sfux@eu-login-40:~$ cargo new hello
    Creating binary (application) `hello` package
error: Failed to create package `hello` at `/cluster/home/sfux/hello`

Caused by:
  failed to read `/cluster/home/Cargo.toml`

Caused by:
  Permission denied (os error 13)
sfux@eu-login-40:~$

The automounter tries to mount the home directory of the non-existing user "Cargo.toml" and then returns a "permission denied" error, which cargo cannot handle.

Is there a way to prevent cargo from searching Cargo.toml everywhere in the path of the working directory? Or is there a way to have cargo handling the "Permission denied" without failing?

Any help is appreciated.

Best regards

Sam

@samfux84 samfux84 added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Mar 19, 2025
@epage epage added the A-workspaces Area: workspaces label Mar 19, 2025
@epage
Copy link
Contributor

epage commented Mar 19, 2025

Is there a way to prevent cargo from searching Cargo.toml everywhere in the path of the working directory?

If you add a [workspace] to your package though that doesn't help with cargo new. We have #7871 and rust-lang/rfcs#3279 for a more general point on this.

Or is there a way to have cargo handling the "Permission denied" without failing?

The challenge with this is when the permission denied error is truly an error and would we should fail.

@RalfJung
Copy link
Member

If you add a [workspace] to your package

IIUC, that would mean that every cluster user has to patch every Rust package they download from the web before they can build it. That's not really a solution...

@epage
Copy link
Contributor

epage commented Mar 19, 2025

I never said it was sufficient. They asked for a way to prevent it and I gave one and listed future options for it.

@RalfJung
Copy link
Member

a way to prevent it

"Educate thousands of users to use Rust in a non-standard way" doesn't fall into that category I would argue. If I were operating a cluster I'd be looking for something I can do to fix this for all my users.

@samfux84
Copy link
Author

Hi,

a quick status update from our side. Our system administrator has now implemented an exception in the automounter script for Cargo.toml, such that it will return a "file not found" instead of "permission denied".

Now cargo works on the cluster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-workspaces Area: workspaces C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

3 participants