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
Related
I'm working on a git project that has a Dockerfile. When I run ls -l in the .git/objects repo, some of the "xx" directories are owned by me, with permissions 777, and some of the "xx" directories are owned by root, with permissions 755.
When I look into the directories owned by me, some or all of the hashed files will be owned by me with 777 permissions, and maybe some owned by root, with 444 permissions. When I look into the directories owned by root, all of the hashed files are owned by root with 444 permissions.
It seems that I might have run my container with root as container's user, which is why I get root as file owner in some parts of my repository.
I want to use Docker to help run and manage my code, but clearly the way I was using it was causing problems. Do I just need to run Docker as my normal user? If I ran all my git operations outside of the Dockerized terminal, that would probably avoid this as well, right? Or is there something else I can or should do?
Thanks for any and all feedback/advice
When I attempt to create ssh keys on my Debian instance :
ssh-keygen -f /home/serverkeys/.ssh/id_rsa
I am getting the error : Saving key "/home/serverkeys/.ssh/id_rsa" failed: No such file or directory
I am using root user and when I check permissions on the directory :
ls -ld
I get
drwxr-xr-x 2 root root 4096 Oct 17 08:32 .
I have a number of questions :
1)What am I missing and why is the system not able to automatically create the .ssh directory specified ?
2)Do I need to create another user and switch from using root. I am not sure if the new user will inherit permissions on all packages I have so far since I have installed them with root user profile?
I intend to use the ssh keys for integration between Jenkins and Gitlab as outlined here Jenkins_Gitlab .In the example however the Jenkins instance and Gitlab instance are installed on different servers and yet for my setup they are installed on the same Debian instance and also my Gitlab repo is public.
I am unsure as to whether I still need the ssh key because Jenkins and Gitlab are running on same Debian instance eg would Jenkins still need ssh keys in order to checkout the code from Gitlab.
When you want to save your ssh key in a specified folder write the folder name without quotation that works for me.
Enter file in which to save the key (/home/rakiiibul/.ssh/id_rsa): /home/rakiiibul/Desktop/sshkey
Since you are already using a root user you don't need to create another user.here is screenshot of that
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
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'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