Permission denied error when debugging as default vscode user

[danofiveo]

Problem

After cloning this repo in a remote host via SSH and selecting the "Reopen in Container" command, the container is configured as expected. However, when I attempt to debug, I'm presented with the following output:

Running `cargo build --bin=hello_remote_world --package=hello_remote_world --manifest-path=Cargo.toml --message-format=json`...
error: failed to open: /workspaces/vscode-remote-try-rust/target/debug/.cargo-lock

Caused by:
  Permission denied (os error 13)
Error: Cargo invocation failed.
        at t.Cargo.getCargoArtifacts (/home/vscode/.vscode-server/extensions/vadimcn.vscode-lldb-1.10.0/extension.js:1:14881)
        at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
        at async Object.open (/home/vscode/.vscode-server/extensions/vadimcn.vscode-lldb-1.10.0/extension.js:1:13191)
Caused by: Error: exit code: 101.
        at ChildProcess.<anonymous> (/home/vscode/.vscode-server/extensions/vadimcn.vscode-lldb-1.10.0/extension.js:1:16548)
        at ChildProcess.emit (node:events:518:28)
        at maybeClose (node:internal/child_process:1105:16)
        at ChildProcess._handle.onexit (node:internal/child_process:305:5)
 *  The terminal process failed to launch (exit code: 1). 

Also, if I edit one of the included files and attempt to save it, I'm presented with the following error:

Failed to save 'devcontainer.json': Unable to write file 'vscode-remote://dev-container+<omitted for brevity>@ssh-remote+debian-machine/workspaces/vscode-remote-try-rust/.devcontainer/devcontainer.json' (NoPermissions (FileSystemError): Error: EACCES: permission denied, open '/workspaces/vscode-remote-try-rust/.devcontainer/devcontainer.json')

How can the default vscode user have a full developer experience as expected?

The Docker engine is running as non-root user (rootless mode).

Workaround

Uncomment the "remoteUser": "root" line in the devcontainer.json file.
Run the container as root.
Debugging proceeds without permission errors.

Tried So Far

Changing owner and group:

vscode ➜ /workspaces/vscode-remote-try-rust $ sudo chown -R vscode:vscode .

Results in different errors when attempting to debug:

/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /workspaces/vscode-remote-try-rust/target/debug/hello_remote_world)
/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /workspaces/vscode-remote-try-rust/target/debug/hello_remote_world)
/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /workspaces/vscode-remote-try-rust/target/debug/hello_remote_world)

Am I missing something?
What should I do to be able to debug Rust running as the default vscode user?

[samruddhikhandale]

@gauravsaini04 / @prathameshzarkar9 Can either of you help investigate the issue? thanks!

[prathameshzarkar9]

Hi @samruddhikhandale ,
I have tried to reproduce the error - seems like the mentioned error is not seen while I was trying to debug the rust code in dev containers
Kindly refer the following snapshot of the debugging:

Used following configuration:

// README at: https://github.com/devcontainers/templates/tree/main/src/rust
    {
    	"name": "Rust",
    	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    	"image": "mcr.microsoft.com/devcontainers/rust:1-1-bullseye",
    	// Features to add to the dev container. More info: https://containers.dev/features.
    	// "features": {},
    	// Configure tool-specific properties.
    	"customizations": {
    		// Configure properties specific to VS Code.
    		"vscode": {
    			"settings": {},
    			"extensions": [
    				"streetsidesoftware.code-spell-checker"
    			]
    		}
    	}
    	// Use 'forwardPorts' to make a list of ports inside the container available locally.
    	// "forwardPorts": [],
    	// Use 'postCreateCommand' to run commands after the container is created.
    	// "postCreateCommand": "rustc --version",
    	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    	// "remoteUser": "root"
    }

[danofiveo]

My configuration looks to be exactly the same as yours:

The rust-analyzer popup shows permissions errors, which could be why I'm getting similar errors while debugging in the container:

Prior to debugging the following permission errors are displayed in the Rust Analyzer Language Server output panel:

2024-08-02T06:25:16.238460Z ERROR Failed to discover cargo config env: cd "/workspaces/vscode-remote-try-rust" && RUSTC_BOOTSTRAP="1" RUSTUP_TOOLCHAIN="/usr/local/rustup/toolchains/1.79.0-x86_64-unknown-linux-gnu" "/usr/local/cargo/bin/cargo" "-Z" "unstable-options" "config" "get" "env" failed, exit status: 101
stderr:
error: config value `env` is not set


Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
   1: project_model::utf8_stdout
   2: project_model::env::cargo_config_env
   3: project_model::workspace::ProjectWorkspace::load
   4: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: core::ops::function::FnOnce::call_once{{vtable.shim}}
   7: std::sys_common::backtrace::__rust_begin_short_backtrace
   8: core::ops::function::FnOnce::call_once{{vtable.shim}}
   9: std::sys::pal::unix::thread::Thread::new::thread_start
  10: start_thread
  11: clone
2024-08-02T06:25:16.415512Z ERROR FetchBuildDataError:
error: Permission denied (os error 13) at path "/workspaces/vscode-remote-try-rust/targetHHPX6Q"


2024-08-02T06:25:16.719856Z ERROR Failed to discover cargo config env: cd "/workspaces/vscode-remote-try-rust" && RUSTC_BOOTSTRAP="1" RUSTUP_TOOLCHAIN="/usr/local/rustup/toolchains/1.79.0-x86_64-unknown-linux-gnu" "/usr/local/cargo/bin/cargo" "-Z" "unstable-options" "config" "get" "env" failed, exit status: 101
stderr:
error: config value `env` is not set


Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
   1: project_model::utf8_stdout
   2: project_model::env::cargo_config_env
   3: project_model::workspace::ProjectWorkspace::load
   4: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: core::ops::function::FnOnce::call_once{{vtable.shim}}
   7: std::sys_common::backtrace::__rust_begin_short_backtrace
   8: core::ops::function::FnOnce::call_once{{vtable.shim}}
   9: std::sys::pal::unix::thread::Thread::new::thread_start
  10: start_thread
  11: clone
2024-08-02T06:25:16.829602Z ERROR Flycheck failed to run the following command: CommandHandle { program: "/usr/local/cargo/bin/cargo", arguments: ["check", "--workspace", "--message-format=json-diagnostic-rendered-ansi", "--manifesIt-path", "/workspaces/vscode-remote-try-rust/Cargo.toml", "--keep-going", "--all-targets"], current_dir: Some("/workspaces/vscode-remote-try-rust") }, error=Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(25856))):
error: Permission denied (os error 13) at path "/workspaces/vscode-remote-try-rust/targetPwKI4a"

I assume you're running as the vscode user. Is this correct?

I'm not sure if it matters, but I'm using a Linux OS on all three tiers:
Local machine (Debian 12) -> SSH remote host (Debian 12) -> Container (Debian 11)
Is it the same for you?

How should I troubleshoot the permission errors?

[danofiveo]

One more thing. On the remote host, Docker is running in rootless mode:

[danofiveo]

Hi @samruddhikhandale / @prathameshzarkar9 ,

After rebuilding the virtual machine (remote host) and configuring Docker, but this time not enabling Docker Rootless mode, the devcontainer works as expected w/o the previous permission errors:

I think we can conclude that the permissions errors only occur when Rootless mode is enabled. You should be able to reproduce the errors by enabling Rootless mode as described here:
https://docs.docker.com/engine/security/rootless/