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.
Related
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
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 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
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
After extracting and saving the ant files into an opt/ directory and setting the path variable
to $ANT_HOME/bin
I ran the following command on a CentOS 5
ant -version
and I am getting the following error
-bash:/path/opt/apache-ant-1.8.2/bin/ant: Permission denied
Is there some permission I am supposed to set or some typical source of this problem?
Thanks!
If you own the file, try
chmod u+x /path/opt/apache-ant-1.8.2/bin/ant
If someone else owns it, either sudo or become root then
chmod 755 /path/opt/apache-ant-1.8.2/bin/ant
You need to have execute permissions on the file; the first gives execute permissions to the owner only and is probably preferable if you own the file and are the only one that uses it. The second requires root privileges and gives execute and read permission to everyone, plus write permission to the owner.
You can view the current permissions and ownership of the file by running ls -l /path/opt/apache-ant-1.8.2/bin/ant.