Question
Permission denied on sudo mkdir in before task for GitPod production workspace
Ash Maple
0 reputation · 05 Feb 2021, 09:34 UTC
37.9K views1
Loading…
0 reputation · 05 Feb 2021, 09:34 UTC
When a before task in .gitpod.yml attempts to create a directory under /workspace using sudo mkdir -p, the command succeeds in a workspace started locally with the gp CLI but fails with a permission denied error in a workspace launched from the GitPod dashboard (production).
Determine why the same before task behaves differently between local CLI workspaces and production hosted workspaces, focusing on the privilege and execution context of the sudo command.
The before task runs during container initialization; the local workspace may reuse a cached image and execute as the user that invoked gp, whereas production workspaces start from a freshly pulled image and may run under a different user namespace or with dropped capabilities. It is unclear whether the failure stems from the user under which the task runs, the availability of sudo, or security options (e.g., nosuid) applied to the /workspace mount in production.
before task execute under in a production workspace?sudo return a permission denied error despite the image containing the binary?init user, sudo enablement) that affect privilege execution in the before task?35275 reputation · 05 Feb 2021, 10:27 UTC
The before task runs as the user defined in .gitpod.yml (default gitpod, UID 1000). In the production‑launched workspace the image’s sudoers file is hardened and does not grant password‑less sudo to that user, so sudo mkdir -p returns “permission denied”. A workspace started locally with the gp CLI often re‑uses a cached image or is launched with the invoking user’s UID/GID or with root privileges, allowing the same command to succeed.
gitpodbefore task executes under the user specified by the user field (or the default gitpod user)./workspace volume is owned by that user, so mkdir works without sudo when the task runs as that user.sudoers with a restrictive version that removes the gitpod user’s NOPASSWD entry.The failure is due to missing sudo privileges for the executing user, not to mount options such as nosuid or to the presence of the sudo binary.
id && sudo -l && ls -ld /workspacegitpod (UID 1000) and sudo -l lists no allowed commands, you have two options:
sudo because the user already owns /workspace:
mkdir -p /path/to/dir.gitpod.yml by setting user: root or adding sudo: true to the task (if the image permits it).
After applying one of the fixes, re‑run the workspace from the GitPod dashboard and verify that the directory is created without error.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.