How to give permission for the cron job file? - cron

I have set the cron tab for my site. But I have got message in my mailing id like this "Permission denied" for the script. Can anyone help me telling what may be the problem.
Thanks......

You get this error while setting the crontab? or from a script running from the cron?
If while setting the crontab, try this:
You type: crontab -e
You get: -bash: /usr/bin/crontab: Permission denied
Problem: Your user is not in the cron group.
Solution: As root, edit the /etc/group file, find the cron group and add
your user to that line (the usernames are comma-separated).
Then re-login as your user.
Verify: Run command "groups". You should see "cron" in there.
(from http://www.parseerror.com/argh/crontab-e-Permission-denied.txt)

friends if any one wants schedule crons from other user
just do this
root user:-
ls /usr/bin/crontab
chmod 4755 /usr/bin/crontab
echo PATH
vi /etc/crontab
SHELL=/bin/bash
PATH=/usr/java/jdk1.5.0_22/bin:/root/bin:/usr/java/jdk1.5.0_22/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
MAILTO=root
HOME=/
cd /etc/cron.d
create cron.allow file if not exist
vi cron.allow
root
other username
save and exist
su – username
/usr/bin/crontab -e
schedule here ……………….

I ran into this issue today and was baffled until I realized that the denied commands were SSH commands. I had forgotten that I was connecting with an SSH key that required a passphrase, so the real issue had nothing to do with cron in my case.
My solution was to create an additional key for this script with no passphrase (using ssh-keygen), install it on the remote server, and specify it in the script with the -i flag to the ssh commands.
ssh -i /path/to/id_rsa.no-passphrase user#remote command-to-run

Related

Crontab executes shell script: Mount error(13): Permission denied

I have got a RasPi and I actually try to execute a shellscript to automount a folder at every Reboot.
Script Command is:
sudo mount -t cifs 'folderpath' 'pointtomount' -o username=xxx,password=xxx,sec=ntlm
It works perfect if I use it manually but via cronjob it responses "Mount Error(13): Permission denied" and the mount can't be executed.
Means cronjob executes the file at least.
My idea was to mount it manually and check if automount is disabled in /etc/fstab or /etc/mtab. As it's just a folder I only found it in mtab.
I can't write in it but nowhere's "noauto" in the options so probabbly everything is correct.
Not certain if it has sth. in common with crontab execute rights but ls -lha /usr/bin/crontab output is -rwxr-sr-x 1.
If anyone of you got any clues how to solve this problem, i'd appreciate help.
Thanks
EDIT1:
Okay after hours and hours it seems to be working in /home/pi/.config/lxsession/LXDE-pi/autostart.sh (type "sudo nano /home/pi/.config/lxsession/LXDE-pi/autostart.sh"). In that file I wrote "#/home/pi/scripttoexecute.sh". In my executescript I wrote "sudo mount -t cifs 'foldertomount' 'directorypath' -o credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777,sec=ntlm". Obviously to use the smbcredentials file, write "sudo nano /root/.smbcredentials" and in there "username=xxx" and next line "password=xxx" and optional domain.
Thanks to all and I hope that this might save someone elses time.
Not sure if it has sth in common with apt-get upgrade and apt-get update before.
Couple things here, first off every user can have their own crontab. For example:
crontab -e # Edit crontab of current user
crontab -u root -e # Edit crontab of root user (might need sudo for this)
crontab -u www-data -e # Edit crontab of www-data user
Another thing is that if you don't use crontab -e to edit the file, and actually edit the /etc/crontab file directly (do something like vim /etc/crontab), you can actually specify the user you'd like to run the cron as:
* * * * * root mount -t cifs /path/to/folder /point/to/mount -o username=xxx,password=xxx,sec=ntlm
To run via root's crontab at reboot, type:
sudo crontab -e
And add this line:
#reboot mount -t cifs 'folderpath' 'pointtomount' -o username=xxx,password=xxx,sec=ntlm
But really, shouldn't you be adding your auto-mounts to /etc/fstab?

Incron job is not being executed

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

Run script as another user on Linux

I am trying to create a Linux terminal menu by way of a simple script. Within the script it will have some commands that will submit a job (a shell script for example) as another user without password prompt.
I was able to find the following post and this worked. how to run script as another user without password
However, there was one side affect. It appears the user can run other scripts in that users folder which I don't want.
Any suggestions/help welcome.
For the sake of this. Here is what I have:
Username temp1, which is the user that will be running the menu.
uid=1001(temp1), gid=1001(temp1), groups=1001(temp1)
Username wayne, which is the user that the script must be submitted as to run the job
uid=1000(wayne), gid=1000(wayne),groups=1000(wayne),4(adm),24(cdrom),27(sudo),30(dip)...
Script script1.sh, script2.sh owned by wayne.
-rwxr-xr-x script1.sh
-rwxr-xr-x script2.sh
If I try to go to /home/wayne as temp1 user I get permission denied (expected)
I set the scripts to chmod 700 for wayne. So technically no one can run them other than wayne.
I have edited sudo file and have the following entry:
temp1 ALL(wayne) NOPASSWD: /home/wayne/script1.sh
When I run command su -c "/home/wayne/script1.sh" -s /bin/sh wayne the script runs (as expected)
When I run command su -c "/home/wayne/script2.sh" -s /bin/sh wayne the script runs (not expected).
Any ideas?
The answer is change from su to sudo.
su is primarily for switching users, while sudo is for executing commands as other users. The -u flag lets you specify which user to execute the command as:
sudo -u wayne '/home/wayne/script2.sh'
gives Sorry user is not allowed to execute
Solution: In order to run commands/scripts as another user on linux/unix you need sudo permission and run the following formula:
sudo -H -u <user> bash -c '<some-command>'
For example:
sudo -H -u wayne bash -c 'echo "user:$USER|home:$HOME|action:run_script"; ./home/wayne/script.sh'
from Documentation:
sudo allows a permitted user to execute a command as the superuser or
another user, as specified by the security policy.
-H The -H (HOME) option requests that the security policy set
the HOME environment variable to the home directory of the
target user (root by default) as specified by the password
database. Depending on the policy, this may be the default
behavior.
-u user The -u (user) option causes sudo to run the specified
command as a user other than root. To specify a uid
instead of a user name, use #uid. When running commands as
a uid, many shells require that the '#' be escaped with a
backslash ('\'). Security policies may restrict uids to
those listed in the password database. The sudoers policy
allows uids that are not in the password database as long
as the targetpw option is not set. Other security policies
may not support this.

How to supply sudo with password from script?

Please note: this is a guest VM (VBox) running on my local machine, and I'm not worried about security.
I am writing a script that will be executed on a Linux (Ubuntu) VM as the myuser user. This script will create a very large directory tree under /etc/myapp. Currently I have to do all this manually, and it starts with me giving myuser recrusive rwx permissions under /etc like so:
sudo chmod -R 777 /etc
[sudo] password for myuser: <now I enter the password and hit ENTER>
My question: how do I write a bash script that supplies the sudo command with my password so that I can just execute bash myscript.sh and it will make the necessary permission changes for me?
(BASH)
OK, if you've gotta do it, (keeping security warnings in mind):
$ sudo -S < <(echo "<your password>") <your sudo command>
If, as you say, you completely don't care about security...
Run visudo to edit /etc/sudoers with validation in place. Add the following line:
ALL ALL=(ALL) NOPASSWD: ALL
This will prevent sudo from ever asking for a password, for any user, for any command.
You can use expect or autoexpect. It's a bad idea, though.
Never put system passwords into writing. At least, not on a file on said system. Much less on an install script known to require root access. You're making yourself an easy target.
What you do instead, is configure sudo via /etc/sudoers/ to allow exactly that user to execute exactly that script without a password:
myuser ALL=(ALL) NOPASSWD : /path/to/script
Note:
If you remove the /path/to/script part, myuser will be able to sudo anything with no password.
If you change myuser for ALL, everyone will be able to run that script with no password.

Running Remote Root Scripts on Fedora

I'd like to automate root scripting actions on my remote Fedora server via SSH without having to install the scripts on the server. To do this, I'm trying to use Bash's inline script notation. This works fine in Ubuntu, but I'm getting strange errors on Fedora.
e.g.
#!/bin/bash
ssh -t myuser#myserver <<EOI
su -
ls /root
exit
exit
EOI
This gives me the output:
standard in must be a tty
ls: cannot open directory /root: Permission denied
I've also tried:
#!/bin/bash
ssh -t myuser#myserver <<EOI
sudo ls /root
exit
EOI
but this gives me:
sudo: no tty present and no askpass program specified
If I manually ssh in and run these commands, they run fine since myuser is in the sudoers file. I've Googled these errors and have tried some fixes, but nothing's worked so far. How do I resolve this?
Looks like you're being prompted for the password but have no way to enter it. Here's a few things that should help.
Try an extra -t option: ssh -tt myuser#myserver <<EOI
Also this is a handy trick to log on as root without the root password being enabled: sudo su -
As a last resort you can setup your user to sudo without a password using visudo. You might see some comments like these to help you out:
# Uncomment to allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
# %sudo ALL=NOPASSWD: ALL

Resources