Skip to content

Linux toolchain unpack leaves bin/* without execute permission (644) #4900

Open

Description

@AlexMikhalev

Summary

After rustup update / toolchain install on Linux, binaries under $RUSTUP_HOME/toolchains/*/bin/ can be installed with mode 644 (-rw-r--r--) instead of 755, causing immediate failures:

error: Permission denied (os error 13)

when invoking cargo, rustc, rustfmt, etc.

Environment

  • OS: Linux x86_64 (ext4)
  • rustup: 1.29.0 (28d1352 2026-03-05)
  • RUSTUP_HOME: ~/.rustup (default)
  • umask: 022
  • Reproduced: 2026-06-08 after rustup update stable

Steps to reproduce

rustup --version
rustup update stable   # or: rustup toolchain install stable

find "$RUSTUP_HOME/toolchains" -path '*/bin/*' -type f ! -perm -111 -print | head
stat -c '%a %n' "$RUSTUP_HOME/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo"

cargo --version   # may fail with os error 13 if 644

Expected behaviour

Toolchain binaries under toolchains/*/bin/ are executable (mode includes +x, typically 755 with umask 022).

Actual behaviour

Some or all toolchain bin/* files are 644. The rustup shim itself remains executable; only unpacked toolchain components are affected.

Impact

Breaks CI runners and automation that calls cargo/rustfmt immediately after a toolchain refresh.

Workaround

find "$RUSTUP_HOME/toolchains" -path '*/bin/*' -type f ! -perm -111 -exec chmod +x {} +

Additional notes

  • Default ~/.rustup was used (no custom relocation).
  • Historical toolchains on the same host also showed 644 on bin/*, suggesting unpack/install rather than backup restore.

Activity

  1. rami3l commented on Jun 11, 2026

    @rami3l
    Member

    @AlexMikhalev Hello, as far as I know rustup's logic of determining the FS permissions of unpacked files is as follows, based on the tar_mode:

    let tar_mode = entry.header().mode().ok().unwrap();
    // That said, the tarballs that are shipped way back have single-user
    // permissions:
    // -rwx------ rustbuild/rustbuild ..... release/test-release.sh
    // so we should normalise the mode to match the previous behaviour users
    // may be expecting where the above file would end up with mode 0o755
    let u_mode = tar_mode & 0o700;
    let g_mode = (u_mode & 0o0500) >> 3;
    let o_mode = g_mode >> 3;
    let mode = u_mode | g_mode | o_mode;

    This means only a tar with mode 0o6xx in the header can generate 0o644 files. In other words, it doesn't look like a rustup problem, but a problem with the files it downloads.

    Is there anything special about your setup in that regard? Are you downloading from a corporate archive of Rust releases? Are you downloading nightlies? Stables should be quite hard to have that problem, otherwise many must have noticed already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    incompleteThe bug report does not have enough informationquestion

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions