I have a shell script prepared and tested successfully in testbed (linux) server, and I have moved this to my production server (under same user, group which I have used in testbed) with read/write/execute permissions. when I execute script in production it gives error, because redirect files get generated in by script (in same folder) with no permission (--------), hence my scripting gets failed.
I had not faced this problem in testbed server, I have tested my script successfully under user level only.(not root user level)
I already tried giving user/group permission for my script folder/files, and user/group are same one's that I have successfully tested in testbed Linux server.
how I moved my script to production:
unzip -K script.zip
chmod 777 script.zip
cd scriptfolder
./execute.sh
generated redirect file (gmon.out) in same script folder
ls -lrt
---------- 1 user group 42023 May 15 10:00 gmon.out
expected redirected file
-rw-r----- 1 user group 42023 May 15 10:00 gmon.out
Please help
This is probably because of the umask, as noted by Socowi in the command.
Umask dictactes the permission of any new file you create.
You can check the current value of umask with the umask command.
You can change the umask in your profile file (like your .bashrc if you use bash) with the umask 0027 command, for instance.
For more information about umask :
https://fr.wikipedia.org/wiki/Umask
http://man7.org/linux/man-pages/man1/umask.1p.html
Related
I am currently working on a bash script which has a user that is created for the job it is running. The user does not exist outside of the script. I am trying to test my code coverage while leaving the user intact.
exec aa-exec -p test-user -- coverage run --source=/test/server ./main.py
The problem is that the test-user does not have access to the code coverage folder. After running chmod -R 777 /usr/local/bin/coverage I still get /usr/bin/python: can't open file '/usr/local/bin/coverage': [Errno 13] Permission denied. I have also tried to temporarily elevate the user inside the bash script using sudo, but because the user only exists inside the file, the sudoers file throws an exception.
I am currently out of ideas since the permissions for this user have to remain restricted ideally. Any suggestions?
Have you checked, that the user has access to each of the directories above?
I.e. the user needs to have 'x' and 'r' rights to each of these directories:
/usr
/usr/local
/usr/local/bin
I have an issue executing a script from another directory using a full path.
For example, user jnh has the script in its home directory(/home/jnh):
# ls -l
total 4
-rwxr-x--- 1 jnh tstgrp 120 Mar 12 16:39 test.run
Now, when I log in as jnh and go to another directory such as /apps and execute the script using the full path, I got an error message:
# /home/jnh/test.run
touch: cannot touch `test.txt': Permission denied
Any idea? Thank you in advance!
Joie
I think your problem is a permissions problem not a scripting problem. Does user jnh have write permission on the directory /apps? Because you are running the script from /apps it's the working directory, and thats where it is trying to create the file, so the user that is running the script must have permissions to do so.
I am using incron to monitor one of my file in /var/www/html directory.
output of incrontab -l
/var/www/html/test IN_ACCESS /home/intel/test.sh
This job is supposed to create a file in home directory, But when this job got executed (I opened the web address in browser), no file is created, following line is whon shown in /var/log/cron file
Jan 20 10:27:57 localhost incrond[26442]: (root) CMD (/home/intel/test.sh)
This clearly shows that event had occurred.
P.S: If I just run a /home/intel/test.sh in CLI its works fine and creates test file, following is my test.sh file.
#!/bin/bash
touch fm00
Mostly this problem occurs due to script file permission and ownership of script files. The same problem was faced by me. I found that my scrip owner was not a super user e.g. root.
So, you have to set the permission and ownership of your scrip as super user. Find below.
First of all edit your crontab as super user.(in RHEL like below)
[abc#host] crontab -e
and save crontab :wq!
Now set permission for script
[abc#host] chmod +x script.sh
[abc#host] chown root:root script.sh
Now restart your crontab.(in RHEL like below)
[abc#host] /etc/init.d/crond restart
On a Ubuntu machine I've setup a SVN repository, served with Apache.
All the SVN repository folders and subfolders (located under /var/svn/repos/) belongs to www-data user and group:
drwxr-xr-x 7 www-data www-data 4096 gen 21 10:38 software_repository
www-data is the Apache user.
Next I've a cron job that makes a nightly svnadmin dump of the repository, using my home user, let's say john_doe (joining the www-data group too). svnadmin dump command (and more...) are contained in a sh file called by the crond.
During cron job or launching it manually using user john_doe I get:
svnadmin: E160052: Revprop caching for '/var/svn/repos/sw/software_repository/db' disabled because SHM infrastructure for revprop caching failed to initialize.
svnadmin: E000013: Can't open file '/var/svn/repos/sw/software_repository/db/rev-prop-atomics.mutex': Permission denied
Because of Permission denied error, I've run the same sh script prepending sudo command, and everything works fine.
So, we have 2 possibilities:
Understand where the SVN error come from.
Change permissions in a correct way for the john_doe user, used by cron.
For point #1 I've done some Google search but I've found nothing...
For point #2, I think the correct way is not to set all permissions (recursively) of the group www-data to all SVN folders and subfolders. What it could be done is to share permissions on SVN folders between www-data user and john_doe. Or give to the www-data group the same permissions (recursively) of the www-data user. Or something else, but for both solutions I've no idea of the correct command or configuration setting.
Solved running command:
chmod -R g=u software_repository
This fix is for solution 2. By the way I've no clue where the SVN errors come from...
I'm trying to give read permissions to lighttpd access logfiles to normal users which are on the same system.
The permissions are currently:
-rw-r--r-- 1 www-data www-data 211K Feb 28 11:27 /var/log/lighttpd/access.log
So, if I understood correctly others have read permissions. Unfortunately this doesn't seem to work. If I try to read this file with an user account I get:
/var/log/lighttpd/access.log: Permission denied
I already tried to add the user to the group www-data which didn't work as well.
Any hints what I'm doing wrong here?
To access a file, the system needs the execute permission on all the directories containing the file.
In this case it was necessary to issue the chmod o+x /var/log/lighthttps command (after making sure that the user belongs to the "other" part of the permission set).
The "execute" permission for a directory allows you to enter it. The "read" permission for the directory allows you to see the names of the files inside. The interesting thing is that you can give the x permission alone, what means that anyone can access the files inside, but he needs to know its names.
You might not have execute permission for the lighthttpd so the directory does not give the permission to access its containing file.
Use the command to set the execute permission to that directory.
chmod +x /var/log/lighthttpd