I have a jenkins running on CentOS 8 and a simple job who should write something in a text file.
echo "Hello" > /home/dev/Git/Test.txt
The target directory should be Git:
[dev#h2899618 ~]$ ls -l /home/dev/
insgesamt 12
drwxrwxr-x 3 dev dev 4096 7. Okt 20:54 Git
The user dev has the following permissions:
[dev#h2899618 ~]$ /usr/bin/id
uid=1002(dev) gid=1002(dev) Gruppen=1002(dev),10(wheel),48(apache),991(jenkins),994(docker)
Jenkins uses the following permissions (validated with executing /usr/bin/id inside of the job):
uid=996(jenkins) gid=991(jenkins) groups=991(jenkins)
The job failed with the message:
[Test4Jenkins] $ /bin/sh -xe /tmp/jenkins3692200929413510467.sh
+ /usr/bin/id
uid=996(jenkins) gid=991(jenkins) groups=991(jenkins)
+ echo Hallo
/tmp/jenkins3692200929413510467.sh: line 3: /home/dev/Git/Test.txt: Permission denied
So why jenkins hasn´t the permission to write this directory?
So, you have drwxrwxr-x 3 dev dev 4096 permissions which means that user dev can do whatever, users that are in the group dev can do whatever, others, including jenkins do not have write bit and cannot modify directory content. However, adding this bit by executing chmod o+w /home/dev/ will resolve the issue nut in the worst way because you are giving to one user permissions on the home folder of another user. Better use some dedicated directory, e.g. /var/lib/share. Or even better try to achioeve your goals in such a way that does not require Jenkins to access anything but it's own home folder =) good luck!
P.S. you probably wanted to add jenkins user to group dev, not dev to jenkins user
Related
I am recapping on git in preparation for a project at work and I am falling at the first hurdle when trying to initialise a repo.
I ran the following in GIT BASH (opened as administrator):
cd Users
cd <myuser>
cd Documents
cd git_recap
cd test_project
git init
The last command returns the following error:
C:Users/<myuser>/Documents/git_recap/test_project/.git: No such file or directory
My research tells me that this is a permissions error. I can repeat the exact same steps on my personal computer (not my work one) and it works fine. The problem is that I have no idea which permissions are causing the problem.
I checked the folder permissions for test_project as follows:
cd ..
ls -la
which returns (surmised):
drwxr-xr-x ./
drwxr-xr-x ../
drwxr-xr-x test_project/
I thought: maybe I need to open this folder up for everyone to write to it - fool proof method. I ran:
chmod 777 test_project/
Which returned:
chmod: changing permissions of 'test_project/': Permission denied
I then repeated this process up the folder hierarchy and received the same error message all the way up to the root folder of . I now wanted to see the permissions of all users:
cd ..
ls -la
Which returned:
drwxr-xr-x <myuser>/
To confirm that the issue is with the directory and my permissions within it, I decided to try initialise the repo in the root:
cd <my_user>/
git init
To my surprise, this worked and the repo was succesfully initialised.
Obviously I do not want to initialise my repo here. I want to initialise it in the appropriate test folder.
Any clues what might be wrong and what I might try to correct this?
EDIT
I get identical results when doing the same set of steps from command line (also ran as administrator)
I have stumbled across what I believe is the solution: Windows Security Controlled Folder Access.
This feature is enabled by default on my work laptop and prevents tampering with certain User folders to provide better security in the event of a breach - in particular ransomware.
Unfortunately for me, IT have the power to turn it off - not me.
This is my jenkinx/jenkins_home/workspace folder looks like. (while doing ls -la)
drwxrwxrwx 24 nfsnobody nfsnobody 4096 Sep 29 18:26 workspace
There is a folder inside this workspace. This folder was created by Jenkins automatically when i build a job. This job name is Sandbox_Test-Job
Here's the folder
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Sep 29 18:26 Sandbox_Test-Job
As you can see host machine's user does not have write permission to this folder and the script in the host machine is unable to write to Sandbox_Test-Vinod_M
I will have to manually set the permission first for this folder before the script can write. How can we make sure that when Jenkins create this job folder for each job, the folder has to have write permission for the user in the host?
First, you want to run ls -n to find the real UID/GID of the files/dirs instead of the display names. Next, check to see if that user appears in your /etc/passwd
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
You would need to find the displayed UID in ls -n, not nfsnobody - 65534.
It's unlikely "nfsbody is the owner of the files ( RHEL NFS reference , Linux Home Server HOWTO - Fedora ), more likely the files were written to an nfs volume shared across systems where the UID for jenkins ( run id jenkins) is not the same across them.
Align the UIDs (non-trivial as you must fix the passwd plus the existing ownership UID) and things will then be OK.
Suggested reading from SUSE and ServerFault.
If you're lucky - all the files have one UID and you just need to sync the UID in the passwds, or maybe blow them all away if it's just the workspaces.
ps: Not really a Jenkins issue, better guidance to be found on Serverfault or SuperUser.
pps: there is some help on S/O worth reading as well (search "nfsnobody'):
nfsnobody User Privileges, chown: invalid user: ‘nfsnobody’ in fedora 32 after install nfs
I'm trying to set up continuous deployment of a hugo site using Jenkins on an Ubuntu 16.04 server. I've installed hugo using snap as was recommended on their site. I've been able to get the site working on my main user account, but when I try to have Jenkins do it, it hits this error:
cannot create user data directory: /var/lib/jenkins/snap/hugo/1766: Permission denied
Which seems a little odd because the Jenkins has write permissions to that folder, if I'm reading the permissions correctly:
jenkins#computer: ~$ ls -al /var/lib/jenkins/snap/hugo/1766
total 8
drwxr-xr-x 2 jenkins jenkins 4096 May 11 01:33 .
drwxr-xr-x 4 jenkins jenkins 4096 May 11 01:33 ..
Am I missing something here? Are there other things I need to do?
when I try to have Jenkins do it
Make sure the Jenkins job is actually running as jenkins: add a step in your job to print id -a.
Chances are: it is not running as Jenkins, but as your main account, which does not have the right to write in that folder.
"cannot create user data directory": it is possible 1766 is the id of the user account, created as the user.
Check if creating (as your main account) that 1766 folder, with a chmod 777 (for testing) helps.
Note hugo issue 3143 does mention:
Snaps are read-only for security. We want to prevent a hostile party from sneakily changing the software on your machine, so you cannot modify a snap that is installed on your system. This also means you can always check the signature on the snap, even long after you installed it, to make sure it is still exactly the software you intended. If you want to modify a snap, you can usually build your own version of it, especially if it is open source.
So where can a snap write data? Each snap gets its own set of writable directories which have specific properties. There are two directories which the snap can write to independent of the user. One of these is versioned - each time the snap is upgraded the data is saved and the new snap revision can upgrade its copy. The other ‘common’ data directory is not versioned and is used for big blobs of data that you don’t want to duplicate across revisions of the snap:
/var/snap/<name>/current/ ← $SNAP_DATA is the versioned snap data directory
/var/snap/<name>/common/ ← $SNAP_COMMON will not be versioned on upgrades
Typically, configuration is stored in one of these, along with system-wide data for the snap.
There are also an equivalent two writable directories for each snap in the user home, which can be used to store snap data that is specific to one user or another, separately:
~/snap/<name>/current/ ← $SNAP_USER_DATA that can be rolled back
~/snap/<name>/common/ ← $SNAP_USER_COMMON unversioned user-specific data
You can use the snap edition of Hugo to write (i.e. run hugo new site etc.) anywhere inside your $HOME directory, say ~/tmp/htest, but not in the system-wide /tmp directory.
That matches the "Hugo Install from snap" section:
Hugo-as-a-snap can write only inside the user’s $HOME directory—and gvfs-mounted directories owned by the user—because of Snaps’ confinement and security model.
Use sudo snap install hugo --classic to disable the default security model if you want hugo to be able to have write access in other paths besides the user’s $HOME directory.
I solved this ultimately by:
uninstalling Jenkins with sudo apt-get remove --purge jenkins
creating a standard user account named jenkins
reinstalling Jenkins and
setting the Jenkins Workspace Root Directory to /home/jenkins/workspace/${ITEM_FULL_NAME}
Could also probably be cured by making a directory /home/jenkins that is owned by the Jenkins profile
I have a Rake at the end of which the server moves the processed file from a folder to another one, using FileUtils.mv, like this:
FileUtils.mv('/path-to-upload-folder/'+filename, '/path-to-imported-folder/'+filename) if File.exist?('/path-to-upload-folder/'+filename)
If i run this command from within the rails server (I have an action that is a copy of the rake task, just for simplicity of debugging inside a controller), everything goes fine (probably because I run the server with root privileges with rvmsudo).
When running from the Rake task, I get a permission denied error, like this
Errno::EACCES: Permission denied # sys_fail2 -
The source folder is called uploads, and the destination folder is the imported folder. Following the permissions and the user and groups of the folder
drwxr-xr-x 2 malatini malatini 4096 lug 14 14:26 imported/
drwxr-xr-x 2 www-data www-data 135168 lug 14 14:26 uploads/
where malatini is my current user.
I know that for running a raw mv from the two folders I need to be a sudo user, but why can I run the same command from within the Rails servers without any problem?
I also tried to change permissions and owners/groups of the destination folder, but with no luck.
Reading here I suppose the problem is the user that is running the rake task. The same problem happens either if I manually run the rake task, either if it is run as a cron job.
I am running under
Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
Any suggestion?
EDIT:
As #Nic Nilov suggested I tried to change owner and group of source and destination foleders, and actually I managed to perform the mv, and hence rake task, changing owner and group of both folders to malatini
drwxr-xr-x 2 malatini malatini 4096 lug 14 14:26 imported/
drwxr-xr-x 2 malatini malatini 135168 lug 14 14:26 uploads/
but in this way, apache (which is in charge of moving files to uploads folder) is not able to write to uploads folder. No other configuration is working (not just the group of uploads folder, nor the 777 to imported folder).
You basically answered your own question. This is a permission issue, related to the OS user under which the move operation is attempted. It works from Rails since, as you say, you run it with rvmsudo.
Two ways around that would be to either run your rake task from a privileged user or set ownership on both folders such that the current user you run rake under is allowed to perform mv.
On your folders both user and group set to be the same. You could set their group to the group of the user running rake, e.g.:
chgrp malatini ./uploads
This would make malatini group the owner of both folders:
drwxr-xr-x 2 malatini malatini 4096 lug 14 14:26 imported/
drwxr-xr-x 2 www-data malatini 135168 lug 14 14:26 uploads/
Which should allow the mv operation.
UPDATE
When running rake under a privileged user and doing that from cron and to avoid keeping the password stored anywhere you can use NOPASSWD directive.
See for more details this askubuntu answer.
I'm trying to install Jenkins on a Tomcat 7 container.
When I try to open the Jenkins web app I get following error:
Unable to create the home directory '/home/myuser/jenkins/work'. This is most
likely a permission problem.
To change the home directory, use JENKINS_HOME environment variable or set
the JENKINS_HOME system property. See Container-specific documentation for
more details of how to do this.
Before starting Tomcat, I did chmod uog+rwx /home/myuser/jenkins. So, I suppose that Jenkins should be able to create a subdirectory there.
But obviously it can't.
How can I fix this problem?
Update 1:
lt -lt returns
drwxrwxrwx 2 root ec2-user 4096 Jun 23 10:25 jenkins
for /home/myuser/jenkins. /home/myuser/jenkins/work doesn't exist because Jenkins is supposed to create it.
Update 2: Just tried to create the work directory and to run chmod uog+rwx on it. It didn't help.
Update 3: Additional information:
I need Jenkins in order to
run lengthy tests in the night (fast unit tests are run before every mvn install, slow tests are executed every night) and
save software quality metrics (checkstyle, PMD, FindBugs, unit test coverage etc.) over time.
I have only one machine available for that and there is a Tomcat7 container installed there already.
At the moment, I don't want to invest additional money into buying new machines.
The machine with the Tomcat7 container (and where I want Jenkins to be installed) is an Amazon EC2 microinstance (OS version is given below).
$ cat /etc/*-release
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Amazon Linux AMI release 2013.03
Update 4 (29.06.2013 13:34 MSK): The output of yum list does not contain any Jenkins/Hudson package.
If Tomcat is running as a separate user you will need to give execute permission to your home directory to that user - either by giving it to all or by creating a group especially for you and the tomcat user.
(UPDATE) More specifically: You say you already did chmod uog+rwx /home/myuser/jenkins, if Tomcat is not running asl 'myuser' it also needs execute permission on /home and on /home/myuser to be able to open /home/myuser/jenkins. If you are not picky about other users on the system opening your homedir you could allow this by: chmod a+x /home/myuser. (I'm assuming here the permissions for /home are already ok)
If you are running tomcat as 'myuser' the filsystem permissions look fine, but Tomcat's own permission system might be the problem as webapps are not allowed to touch the filesystem if the default settings of the security manager are on.
See: https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
You don't specify more about your exact Tomcat/OS setup so I can't give exact details, but the fast way to find out if it's a security manager issue is to give AllPermission to you webapp. If you don't run in a safe environment it is advisable to only use that as a test, and setup only the really needed permissions later.
run these three commands
cd /usr/share/tomcat7
sudo mkdir .jenkins
sudo chown tomcat7:nogroup .jenkins
https://seleniumwithjavapython.wordpress.com/home/jenkins-installation/
It looks like the problem may be that jenkins cannot see /home/myuser, and therefore it cannot access the jenkins folder inside this (even though it has write permissions in /home/myuser/jenkins, I believe the fact it can't read /home/myuser causes a problem).
Try running the below command and then see if Jenkins works after that:
chmod +r /home/myuser
#robjohncox Yes - drwx------ 5 myuser myuser 4096 Jun 23 10:25 myuser
you must add +x to this dir to make it possible for jenkins to access it's contents, to be precise whole path has to have +x enabled for everyone.
Also, what commands have you used to move it's home dir from default - possible error is somwhere there. Cheers, Piotr