[JENKINS-46686] Auto-chown option to fix files in workspaces created as root

Docker operations can create files within the workspace that are owned by the root user – it is impossible to clear or remove these files by normal methods (the Jenkins user isn't permissioned).  This commonly happens when someone uses the root user to run a Docker operation with a local directory mapped in as a volume to return artifacts. 

I've noted no less than 4 users having major issues as a result of this problem in the last week (see stack trace at bottom) – but it can result in hanging builds and consuming excessive on-master resources. 

Now, there are a couple ways to add features that can prevent this problem: 

1) Add an "permissionsFix" argument to docker.inside and some other docker commands that goes back and tries to do the needful to fix permissions (probably by launching a docker container that creates a user mapping to Jenkins dynamically and doing a chown). 

2) Add a 'chown' operation to the docker options that launches a special container as above. 

3) Try some custom hack with Docker itself so the container sees a root user internally but it still maps back out to Jenkins (maybe possible?)

 

---
Originally reported by svanoort, imported from: Auto-chown option to fix files in workspaces created as root

• status: Open
  
• priority: Major
  
• component(s): docker-workflow-plugin
  
• resolution: Unresolved
  
• votes: 2
  
• watchers: 4
  
• imported: 2025-12-07
  

Raw content of original issue

Docker operations can create files within the workspace that are owned by the root user – it is impossible to clear or remove these files by normal methods (the Jenkins user isn't permissioned).  This commonly happens when someone uses the root user to run a Docker operation with a local directory mapped in as a volume to return artifacts. 


I've noted no less than 4 users having major issues as a result of this problem in the last week (see stack trace at bottom) – but it can result in hanging builds and consuming excessive on-master resources. 


Now, there are a couple ways to add features that can prevent this problem: 


1) Add an "permissionsFix" argument to docker.inside and some other docker commands that goes back and tries to do the needful to fix permissions (probably by launching a docker container that creates a user mapping to Jenkins dynamically and doing a chown). 


2) Add a 'chown' operation to the docker options that launches a special container as above. 


3) Try some custom hack with Docker itself so the container sees a root user internally but it still maps back out to Jenkins (maybe possible?)