This used to work fine.
      Since a few days (when we installed some plugin updates) we get a "permission denied" or "Operation not permitted" when executing shell in an external workspace.
      When I look at the @tmp workspace I find the script that should have been executed. It has the correct content and executable bits are set:

      $ ls -la /media/Builds/super_ArchiveMerged/155@tmp/durable-bb157cd2/
      total 1
      drwxrwxrwx 2 root root  0 Jan 26 09:47 .
      drwxrwxrwx 2 root root  0 Jan 26 09:47 ..
      -rwxrwxrwx 1 root root 20 Jan 26 09:47 script.sh
      

      The job is running in Ubuntu, the external workspace is a ntlm network share.

      example pipeline script:

      node('linux')
      {
          def exwsAll = exwsAllocate diskPoolId: 'ArchivedBuilds'
          exws  (exwsAll)
          {   shResult=  sh returnStatus: true, script:'ls -la'
              if (shResult!=0)
              {   println "script returned "+shResult
              }
          }
      }
      

      Result:

      java.nio.file.FileSystemException: /media/Builds/super_ArchiveMerged/156@tmp/durable-57ddd5a7/script.sh: Operation not permitted
      	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
      	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
      	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
      	at sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:238)
      	at sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:260)
      	at java.nio.file.Files.setPosixFilePermissions(Files.java:2045)
      	at hudson.FilePath._chmod(FilePath.java:1647)
      	at hudson.FilePath.access$1600(FilePath.java:208)
      	at hudson.FilePath$29.invoke(FilePath.java:1629)
      	at hudson.FilePath$29.invoke(FilePath.java:1626)
      	at hudson.FilePath.act(FilePath.java:1009)
      	at hudson.FilePath.act(FilePath.java:987)
      	at hudson.FilePath.chmod(FilePath.java:1626)
      	at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:122)
      	at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:64)
      	at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:177)
      	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:224)
      	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150)
      	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
      	at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
      	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
      	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
      	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:810)
      	at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
      	at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
      	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
      	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
      	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
      	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
      	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
      	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19)
      	at WorkflowScript.run(WorkflowScript:5)
      	at ___cps.transform___(Native Method)
      	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
      	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
      	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
      	at sun.reflect.GeneratedMethodAccessor516.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:498)
      	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
      	at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
      	at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
      	at sun.reflect.GeneratedMethodAccessor521.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:498)
      	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
      	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
      	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
      	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
      	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
      	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122)
      	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)
      	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
      	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:331)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:243)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:231)
      	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
      	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
      	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:745)

          [JENKINS-49184] executing shell in external workspace fails

          The failure seems to happen when the script permissions shall be changed. And from the ls output, the files  are owned by root. Is your jenkins user  really root?

          And  is changing filepermission allowed on ntlm shares? Or are these set fixed via the mount options?

           

          Björn Pedersen added a comment - The failure seems to happen when the script permissions shall be changed. And from the ls output, the files  are owned by root. Is your jenkins user  really root? And  is changing filepermission allowed on ntlm shares? Or are these set fixed via the mount options?  

          Roman Zwi added a comment - - edited

          Thank you for the hint! No, my Jenkins is not root.
          Got to check the ntlm share - it's possibly caused by the mount options:

          //<server>/<path> /media/Builds cifs credentials=<path>,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

          As I quick workaround I got it working by setting hudson.Util.useNativeChmodAndMode=true (see Jenkins features controlled by properties).
          So it seems to be a side effect of the related change in Jenkins V2.93.

          I wonder how this has been working before; on the other hand it wouldn't be nesseccary to change the permissions as they're already ok...

          Roman Zwi added a comment - - edited Thank you for the hint! No, my Jenkins is not root. Got to check the ntlm share - it's possibly caused by the mount options: //<server>/<path> /media/Builds cifs credentials=<path>,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0 As I quick workaround I got it working by setting hudson.Util.useNativeChmodAndMode=true (see Jenkins features controlled by properties ). So it seems to be a side effect of the related change in Jenkins V2.93. I wonder how this has been working before; on the other hand it wouldn't be nesseccary to change the permissions as they're already ok...

          Roman Zwi added a comment -

          Well, actually the previously mentionied workaround work's on Jenkins master but not on the slaves (although the property is set there too)...

          Roman Zwi added a comment - Well, actually the previously mentionied workaround work's on Jenkins master but not on the slaves (although the property is set there too)...

          Devin Nusbaum added a comment - - edited

          FilePath#chmod should only start newly failing after JENKINS-36088 (which landed in Jenkins Core 2.93) if you are trying to set the setuid or setgid bits, which isn't the case here. I do recall a related report from when I made the change that calls to FilePath#chmod using the native implementations failed silently in some cases (i.e. if the file didn't exist), whereas the NIO code path consistently throws exceptions, so it might be the case that setting the permissions never worked on your systems but an exception was never thrown.

          That said, I don't have any ideas about reverting to the old code path with hudson.Util.useNativeChmodAndMode=true would work on the master but not the agents.

          Devin Nusbaum added a comment - - edited FilePath#chmod should only start newly failing after JENKINS-36088 (which landed in Jenkins Core 2.93) if you are trying to set the setuid or setgid bits, which isn't the case here. I do recall a related report from when I made the change that calls to FilePath#chmod using the native implementations failed silently in some cases (i.e. if the file didn't exist), whereas the NIO code path consistently throws exceptions, so it might be the case that setting the permissions never worked on your systems but an exception was never thrown. That said, I don't have any ideas about reverting to the old code path with  hudson.Util.useNativeChmodAndMode=true would work on the master but not the agents.

            alexsomai Alexandru Somai
            romanz Roman Zwi
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: