-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Jenkins v1.582 / Debian 7
Hi,
It seems that there a regression with a recent patch.
Whem i'm building my application, and archiving it in order to deploy the application, the default permission seems to have changed in *a bad way*.
You can see the screenshot attached that the v1.0.6 has "normal" permission but after a jenkins update, the version 1.0.8 on the screenshot have really weird permissions which prevent the webserver from reading the content of the folder.
(i had to manually set the correct permissions for 1.0.9)
I didn't touch the build script responsible of building the archive or the deployment method between those versions.
I suspect the umask PR thing to be the cause (but this is just a guess) : https://github.com/jenkinsci/jenkins/pull/1397
- is related to
-
-
- Resolved
-
[JENKINS-24987] [Regression] Default permission when archiving a build
tristan bessoussa
created issue -
Because this bug prevent me from deploying without human interaction.
And which setting are you referring to ? If I was aware of a solution I wouldn't bother you in here. Just trying to help by providing the more detail I can.
tristan bessoussa
added a comment - - edited Because this bug prevent me from deploying without human interaction.
And which setting are you referring to ? If I was aware of a solution I wouldn't bother you in here. Just trying to help by providing the more detail I can. You found https://github.com/jenkinsci/jenkins/pull/1397
which includes the line (second commit): only set umask if set in /etc/default/jenkins
referencing https://github.com/jenkinsci/jenkins/blob/master/debian/debian/jenkins.default#L45
So it seemed obvious you knew about this option.
It's also noted in the change log at http://jenkins-ci.org/changelog#v1.579
Does the presence of this option resolve this issue for you?
I wasn't excepting a BC break on a minor update, but my bad on this.
Unfortunatly,
1) I commented the umask in `/etc/default/jenkins` as advised
2) I restarted jenkins `service jenkins restart`
3) I rebuilt the release of v1.0.9 of my application.
The result is the same after extract:,
`drwxr-x--- 12 jenkins jenkins 4096 Oct 1 18:08 v1.0.9`
I tried this again and before launching the build, I ereased all previous v1.0.9 archieved builds. The result is the same.
Does umask need to be set at a particular version to restore original settings ? Or do I need to reset my whole workspace so it can git clone with correct file/folder permission ? (The date still refer to the first time I built this tag)
Thanks for your help 
.
tristan bessoussa
added a comment - - edited I wasn't excepting a BC break on a minor update, but my bad on this.
Unfortunatly,
1) I commented the umask in `/etc/default/jenkins` as advised
2) I restarted jenkins `service jenkins restart`
3) I rebuilt the release of v1.0.9 of my application.
The result is the same after extract:,
`drwxr-x--- 12 jenkins jenkins 4096 Oct 1 18:08 v1.0.9`
I tried this again and before launching the build, I ereased all previous v1.0.9 archieved builds. The result is the same.
Does umask need to be set at a particular version to restore original settings ? Or do I need to reset my whole workspace so it can git clone with correct file/folder permission ? (The date still refer to the first time I built this tag)
Thanks for your help . I'm a bit surprised it didn't work. Add diagnostic output to make sure your umask setting is correct.
Try creating a new job that only touches a file on the master node. What are the permissions?
Try service stop/start instead of restart. Probably useless, but who knows.
Try changing the jenkins init script to completely remove --umask argument.
| Priority | Original: Blocker [ 1 ] | New: Major [ 3 ] |
Ok so,
1) Stop then Restart jenkins has no effect (compared to restart)
I went to the job, deleted the build and the corresponding artifact
Commented out the umask in the init.d script
I stopped/started jenkins
Started the job again
Unzip the archive
Works again.
Thanks.
tristan bessoussa
added a comment - - edited Ok so,
1) Stop then Restart jenkins has no effect (compared to restart)
I went to the job, deleted the build and the corresponding artifact
Commented out the umask in the init.d script
I stopped/started jenkins
Started the job again
Unzip the archive
Works again.
Thanks. | Link |
New:
This issue is related to |
Why are you reporting a bug (Blocker even) instead of just changing the setting you're obviously aware of?