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

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

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Environment:
    • Similar Issues:

      Description

      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....

        Attachments

          Activity

          Hide
          josesa 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.

          Show
          josesa 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.
          Hide
          vitaliel 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.

          Show
          vitaliel 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.
          Hide
          vitaliel Lazu Vitalie added a comment -

          The same permissions problem I get on Ubuntu Jenkins version 1.479

          Show
          vitaliel Lazu Vitalie added a comment - The same permissions problem I get on Ubuntu Jenkins version 1.479
          Hide
          2m 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
          
          Show
          2m 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

            People

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

              Dates

              • Created:
                Updated: