Bitbucket Cloud - Subsequent pipe step run fail with "Permission Denied" error when performing write operation of files/artifacts
Platform Notice: Cloud Only - This article only applies to Atlassian products on the cloud platform.
Summary
When running subsequent Bitbucket pipe steps with the artifact-write operation, the initial pipe executes without any errors. However, the subsequent pipe run encounters a "Permission Denied" error.
pipeline yaml
1
2
3
4
5
6
7
8
9
10
11
pipelines:
branches:
master:
- step:
name: Do the 1st thing
script:
- pipe: abc/pipes-1:1step-1
- step:
name: Do the 2nd thing
script:
- pipe: abc/pipes-1:1step-1In the above pipeline example, the second step "Do the 2nd thing" fails with the following error:
Pipe Error
1
"/pipe.sh: line 9: can't create /opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/abc/pipes-1/{2xxxxxxxx-xxxx-xxx-xxxxxx} : Permission denied."Cause
By default, in subsequent pipe steps, any artifact located under pipe "$BITBUCKET_PIPE_STORAGE_DIR" or "$BITBUCKET_PIPE_SHARED_STORAGE_DIR" directory, has its permissions set to the following, with "nobody" as the owner due to security reasons:
1
-rwxr-xr-x 1 nobody nobodyThe use of "nobody" for ownership is due to the Docker User Namespace Remapping (userns-remap), which is a security feature in Docker that provides an additional layer of isolation by mapping the root user inside a container to a less privileged user outside the container.
It's important to note that this is a common practice for security reasons. The files within the container might have different UID/GID values inside and outside the container due to the remapping process. "nobody" is used to represent the minimal-privileged user outside the container.
Solution
The solution is resetting the ownership of "$BITBUCKET_PIPE_STORAGE_DIR" or "$BITBUCKET_PIPE_SHARED_STORAGE_DIR" directory to the "root" user. This will ensure proper read/write permissions for storing artifacts in subsequent pipe steps.
Use the following command to change ownership:
1
2
3
4
5
chown -R 165536:165536 $BITBUCKET_CLONE_DIR
OR
chown -R 165536:165536 $BITBUCKET_PIPE_SHARED_STORAGE_DIRpipeline yaml
1
2
3
4
5
6
7
8
9
10
11
12
pipelines:
branches:
master:
- step:
name: Do the 1st thing
script:
- pipe: abc/pipes-1:1step-1
- step:
name: Do the 2nd thing
script:
- chown -R 165536:165536 $BITBUCKET_CLONE_DIR
- pipe: abc/pipes-1:1step-1This will help to resolve the "Permission Denied" error during subsequent pipe step runs involving artifact write operation in Bitbucket Cloud.
chmod command
chown: This is the command used to change the ownership of files and directories.
-R: This flag stands for "recursive," which means the ownership change will apply not only to the specified directory but also to all of its subdirectories and their contents.
165536:165536: This is the argument that specifies the new ownership. The numbers "165536:165536" represent the user ID (UID) and group ID (GID) respectively. In Unix-like systems, each user and group has a unique identifier. In this case, the command is changing the ownership of the specified files and directories to the user with UID 165536 and the group with GID 165536.
If the above instructions do not assist in resolving the issue, please raise a support ticket or raise a community support ticket for further assistance with this.
Was this helpful?