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

"Permission denied" due to wrong file system permissions upon update/checkout.

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin

      Currently we are using subversion plugin v1.32 - everything works fine.
      But after upgrading to the latest v1.39 we encounter some weird behavior:

      Upon SVN update i often see a "permission denied" exception.
      (well, update works, but the compiler plugin afterwards reports the "permission denied")
      The updated file has not the (chmod 664) permission as supposed to be, it only has execute rights (chmod 001)?!

      I dunno when this happens or how to get more SVN logging to narrow this down.
      Or what changes from .32 to .39 could be the culprit (svnkit upgrade?)
      But reverting back to .32 solves this problem immediately....

          [JENKINS-13133] "Permission denied" due to wrong file system permissions upon update/checkout.

          Jose Sa added a comment -

          I also had this problem with subversion plugin v1.39. After a workspace wipeout all files checked out had permissions "---------x" (001).

          After upgrading jenkins to 1.467 and plugin 1.40 now all files have the same permission "-rwxrwxr-x" (775) regardless if they had the property set for execution or not.

          This however didn't show in all build slaves, only in the master, where i recently changed from java 1.6 to 1.7 and added the flag -d64 in order to use 64-bit data model and allocate more memory for max-heap.
          After more testing I got to the conclusion that this problem doesn't occur if the flag "-d64" isn't passed to java starting options.

          Jose Sa added a comment - I also had this problem with subversion plugin v1.39. After a workspace wipeout all files checked out had permissions "---------x" (001). After upgrading jenkins to 1.467 and plugin 1.40 now all files have the same permission "-rwxrwxr-x" (775) regardless if they had the property set for execution or not. This however didn't show in all build slaves, only in the master, where i recently changed from java 1.6 to 1.7 and added the flag -d64 in order to use 64-bit data model and allocate more memory for max-heap. After more testing I got to the conclusion that this problem doesn't occur if the flag "-d64" isn't passed to java starting options.

          Lazu Vitalie added a comment -

          Hello,

          I have the same problem with git under OSX.
          I try to run a gradle task from this repository: git://github.com/Assembla/jenkins-build-per-branch.git and I get permission denied for gradlew and indeed when I list file permissions:

          --wxr-x--T   1 jenkins  jenkins  5079 29 Aug 18:05 gradlew
          

          How can I help to address this issue?

          I'm using Jenkins installed from OSX dmg, Jenkins ver. 1.478

          Thanks.

          Lazu Vitalie added a comment - Hello, I have the same problem with git under OSX. I try to run a gradle task from this repository: git://github.com/Assembla/jenkins-build-per-branch.git and I get permission denied for gradlew and indeed when I list file permissions: --wxr-x--T 1 jenkins jenkins 5079 29 Aug 18:05 gradlew How can I help to address this issue? I'm using Jenkins installed from OSX dmg, Jenkins ver. 1.478 Thanks.

          Lazu Vitalie added a comment -

          The same permissions problem I get on Ubuntu Jenkins version 1.479

          Lazu Vitalie added a comment - The same permissions problem I get on Ubuntu Jenkins version 1.479

          I had exactly the same problem using Hudson ver. 2.2.0. Problem was solved by switching java to 32 bit.

          Had permission problems with:

          java version "1.6.0_27"
          Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
          Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
          

          No permission problems with:

          java version "1.6.0_27"
          Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
          Java HotSpot(TM) Server VM (build 20.2-b06, mixed mode)
          

          Was running hudson as a slave on:

          SunOS 5.10 Generic_127111-06 sun4u sparc SUNW,SPARC-Enterprise
          

          Martynas Mickevičius added a comment - I had exactly the same problem using Hudson ver. 2.2.0 . Problem was solved by switching java to 32 bit. Had permission problems with: java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode) No permission problems with: java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) Server VM (build 20.2-b06, mixed mode) Was running hudson as a slave on: SunOS 5.10 Generic_127111-06 sun4u sparc SUNW,SPARC-Enterprise

            Unassigned Unassigned
            myron Myron Boyle
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: