Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45603

Jenkins pipeline shared library permission denied

    Details

    • Similar Issues:

      Description

      In my company we are facing the issue where a simple shared pipeline library that works with Jenkins version 2.46.3 fails with Jenkins 2.60.1 with the following stack trace:

       

      
      [Pipeline] library
      Loading library MMS-jenkins-shared-lib@master
       > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
      Setting origin to git@apdev10cmage001.dca.diginsite.net:PSTeam/MMS-jenkins-shared-lib.git
       > /usr/bin/git config remote.origin.url git@apdev10cmage001.dca.diginsite.net:PSTeam/MMS-jenkins-shared-lib.git # timeout=10
      Fetching origin...
      Fetching upstream changes from origin
       > /usr/bin/git --version # timeout=10
       > /usr/bin/git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
       > /usr/bin/git rev-parse master^\{commit} # timeout=10
       > /usr/bin/git rev-parse origin/master^\{commit} # timeout=10
      [Pipeline] }
      [Pipeline] // stage
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      java.io.IOException: Failed to mkdirs: BEN.M/shared-pipeline-scripted-test/workspace@libs/MMS-jenkins-shared-lib
       at hudson.FilePath.mkdirs(FilePath.java:1170)
       at hudson.plugins.git.GitSCM.createClient(GitSCM.java:742)
       at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1104)
       at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
       at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:108)
       at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.retrieve(SCMSourceRetriever.java:84)
       at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:150)
       at org.jenkinsci.plugins.workflow.libs.LibraryStep$Execution.run(LibraryStep.java:187)
       at org.jenkinsci.plugins.workflow.libs.LibraryStep$Execution.run(LibraryStep.java:139)
       at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
       at hudson.security.ACL.impersonate(ACL.java:260)
       at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:748)
      Finished: FAILURE
      
      

       

       

      All systems are Linux Redhat 6 systems using regular virtual machines.

      The shared library plugin is in both cases version 2.7

       

      Could you please help me identify what is causing this issue? 

       

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          Some filesystem permissions problem I suppose. Cannot be evaluated without steps to reproduce from scratch.

          Show
          jglick Jesse Glick added a comment - Some filesystem permissions problem I suppose. Cannot be evaluated without steps to reproduce from scratch.
          Hide
          nickapos Nick Apostolakis added a comment - - edited

          I have checked the filesystem permissions everything was as expected. I wonder if

          hudson.security.ACL.impersonate(ACL.java:260)

          has anything to do with this. It seems as if that the user session is lost after that line in the stack trace so it reverts to anonymous instead of an authorized user.
          I know that this may seem weird, but what is the impersonate call doing in the stack trace in the first place?

          Please let me know if you need more info to reproduce the behavior, if I recall correctly that library is pretty standard nothing special with it.

          Show
          nickapos Nick Apostolakis added a comment - - edited I have checked the filesystem permissions everything was as expected. I wonder if hudson.security.ACL.impersonate(ACL.java:260) has anything to do with this. It seems as if that the user session is lost after that line in the stack trace so it reverts to anonymous instead of an authorized user. I know that this may seem weird, but what is the impersonate call doing in the stack trace in the first place? Please let me know if you need more info to reproduce the behavior, if I recall correctly that library is pretty standard nothing special with it.
          Hide
          jglick Jesse Glick added a comment -

          No I am talking about filesystem permissions, not Jenkins permissions.

          To evaluate, would need to be able to recreate the problem from scratch in a clean environment. Obviously it does not happen under simple conditions, since I have never heard of it before, tests covering this functionality all pass, etc.

          Show
          jglick Jesse Glick added a comment - No I am talking about filesystem permissions, not Jenkins permissions. To evaluate, would need to be able to recreate the problem from scratch in a clean environment. Obviously it does not happen under simple conditions, since I have never heard of it before, tests covering this functionality all pass, etc.
          Hide
          nickapos Nick Apostolakis added a comment -

          I have double checked the filesystem permissions, there is nothing there preventing Jenkins from creating directories. During my investigation I found
          JENKINS-7823 and JENKINS-16451 that seem a bit similar, and someone mentions that filesystem permissions were changed by Jenkins during the build and that resulted in a similar error.
          I am not sure if that is the case here or not. I think this problem appeared with the recent changes in the security subsystem of Jenkins

          Show
          nickapos Nick Apostolakis added a comment - I have double checked the filesystem permissions, there is nothing there preventing Jenkins from creating directories. During my investigation I found JENKINS-7823 and JENKINS-16451 that seem a bit similar, and someone mentions that filesystem permissions were changed by Jenkins during the build and that resulted in a similar error. I am not sure if that is the case here or not. I think this problem appeared with the recent changes in the security subsystem of Jenkins
          Hide
          jglick Jesse Glick added a comment -

          No hypotheses offhand, sorry.

          Show
          jglick Jesse Glick added a comment - No hypotheses offhand, sorry.
          Hide
          nickapos Nick Apostolakis added a comment -

          I found the solution to the problem. It was related to the workspace root directory found in the Advanced button on the right hand side of the manage Jenkins link.
          It seems that the default value for this in the latest releases has changed.
          If you have an older service and carry forward the old configuration value then this value is different from the new default one.
          If you change the old value to:

          ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}
          

          then everything work all right

          Show
          nickapos Nick Apostolakis added a comment - I found the solution to the problem. It was related to the workspace root directory found in the Advanced button on the right hand side of the manage Jenkins link. It seems that the default value for this in the latest releases has changed. If you have an older service and carry forward the old configuration value then this value is different from the new default one. If you change the old value to: ${JENKINS_HOME}/workspace/${ITEM_FULLNAME} then everything work all right

            People

            • Assignee:
              Unassigned
              Reporter:
              nickapos Nick Apostolakis
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: