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

java.nio.file.NoSuchFileException when materializing ServerKey

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: docker-commons-plugin
    • Labels:
      None
    • Environment:
      jenkins: 2.93
      docker-commons: 1.9
    • Similar Issues:

      Description

      Since https://issues.jenkins-ci.org/browse/JENKINS-36088, materializing a server key triggers an exception:

      15:38:55 java.nio.file.NoSuchFileException: /var/lib/jenkins/.docker/7d36d1a6-4917-4dc8-97b6-2babbb2ae3d7
      15:38:55 at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
      15:38:55 at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
      15:38:55 at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
      15:38:55 at sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:238)
      15:38:55 at sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:260)
      15:38:55 at java.nio.file.Files.setPosixFilePermissions(Files.java:2045)
      15:38:55 at hudson.FilePath._chmod(FilePath.java:1618)
      15:38:55 at hudson.FilePath.access$1500(FilePath.java:197)
      15:38:55 at hudson.FilePath$29.invoke(FilePath.java:1600)
      15:38:55 at hudson.FilePath$29.invoke(FilePath.java:1597)
      15:38:55 at hudson.FilePath.act(FilePath.java:998)
      15:38:55 at hudson.FilePath.act(FilePath.java:976)
      15:38:55 at hudson.FilePath.chmod(FilePath.java:1597)
      15:38:55 at org.jenkinsci.plugins.docker.commons.impl.ServerKeyMaterialFactory.materialize(ServerKeyMaterialFactory.java:86)
      15:38:55 at org.jenkinsci.plugins.docker.commons.impl.CompositeKeyMaterialFactory.materialize(CompositeKeyMaterialFactory.java:69)
      15:38:55 at org.jenkinsci.plugins.docker.commons.impl.CompositeKeyMaterialFactory.materialize(CompositeKeyMaterialFactory.java:69)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder$Perform.executeCmd(DockerBuilder.java:459)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder$Perform.executeCmd(DockerBuilder.java:431)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder$Perform.buildAndTag(DockerBuilder.java:373)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder$Perform.exec(DockerBuilder.java:311)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder$Perform.access$100(DockerBuilder.java:291)
      15:38:55 at com.cloudbees.dockerpublish.DockerBuilder.perform(DockerBuilder.java:262)
      15:38:55 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      15:38:55 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
      15:38:55 at hudson.model.Build$BuildExecution.build(Build.java:206)
      15:38:55 at hudson.model.Build$BuildExecution.doRun(Build.java:163)
      15:38:55 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
      15:38:55 at hudson.model.Run.execute(Run.java:1727)
      15:38:55 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      15:38:55 at hudson.model.ResourceController.execute(ResourceController.java:97)
      15:38:55 at hudson.model.Executor.run(Executor.java:429)
      15:38:55 Build step 'Docker Build and Publish' marked build as failure

      This happens when the new (default) NIO mode is used to perform the chmod: the posix API seems to automatically create the folder, which the NIO implementation expects the file/folder to actually exist.

        Attachments

          Issue Links

            Activity

            Hide
            typz Francois Ferrand added a comment -

            A workaround may be to set the `hudson.Util.useNativeChmodAndMode` system property to `true`, to revert back to the old code (and behavior)

            Show
            typz Francois Ferrand added a comment - A workaround may be to set the `hudson.Util.useNativeChmodAndMode` system property to `true`, to revert back to the old code (and behavior)
            Hide
            typz Francois Ferrand added a comment - - edited

            Not sure how best to fix this:

            • Explicitely create the directory before chmod'ing it (`tempCredsDir.chmod(0600)`)
            • Fix `Filepath.chmod` to create directory or ignore non-existant file in NIO mode (e.g. implement same behavior as 'native' implementation)
            Show
            typz Francois Ferrand added a comment - - edited Not sure how best to fix this: Explicitely create the directory before chmod'ing it (`tempCredsDir.chmod(0600)`) Fix `Filepath.chmod` to create directory or ignore non-existant file in NIO mode (e.g. implement same behavior as 'native' implementation)
            Hide
            jglick Jesse Glick added a comment -

            Please use JIRA issue linking where appropriate.

            Show
            jglick Jesse Glick added a comment - Please use JIRA issue linking where appropriate.

              People

              • Assignee:
                Unassigned
                Reporter:
                typz Francois Ferrand
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: