Permissions problem running disk ops in script from cron job

[SoloScott]

I have a perl script which runs several disk operations on a remote drive during its execution. Running this from the system crontab works fine. However, setting up a user cron job for root, which calls the script, fails running disk operations such as fdisk, mkfs, fsck, e2label, etc. Since the user root has no problem executing these tasks, even in a script, there seems to be a permissions difference when executing tasks from a cron job. Can anyone shed some light or give advice on how to get around this?

Thanks.

 

[Dorga]

Show us the script, and the cron entry?

 

[tarn]

Cron has no concept of environment so either add full paths into your script _and_ _or_ declare environment values in your script or crontab.

You can also source your environment with the . /script in crontab:

3 12 * * * . /path/to/monitor.sh > /dev/null 2>&1

where it is ...*<space>.<space>/path/to.....

But please as suggested by Dorga post your cron & script snipit's

Good Luck,
Laurie.

 

[SoloScott]

The script is too large to show here, but here is a sample command that fails.

Perl Script:
system &quot;fdisk -l /dev/sda1&quot;;

Replacing the fdisk operation in the command with mkfs, fsck, e2label, etc. will fail as well.

User cron job command:
30 12 * * * /usr/bin/perl /root/scripts/TestScript.pl

When a system crontab command is inserted into /etc/crontab, as below, there is no problem running the disk operations, which fail in the above manner:
30 12 * * * root /usr/bin/perl /root/scripts/TestScript.pl

 

[tarn]

Just to add clarity read the following from:

http://www.lysator.liu.se/~forsberg/linux/cron.html

Erik Forsberg
Copyright © 1997-2002 by Erik Forsberg
<SNIP>
The system crontab
The system wide crontab is most often called /etc/crontab. This file should have only important jobs, the file is only writable by root. Mine looks something like this: # /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/etc/ppp

# m h dom mon dow user command
44 5 * * * root run-parts /etc/cron.daily

07 5 * * 7 root run-parts /etc/cron.weekly

00 5 1 * * root run-parts /etc/cron.monthly



As you can see, there is seven fields with information. They are, in correct order: minute, hour, day-of-month, month, day-of-week, user and command. Some of the fields contain stars (*) which means any value will fit.

The first line of my file tells cron that every day (the fields day-of-month, month and day-of-week have stars, so cron doesn't care about them) at 05:44 in the morning I want the command &quot;run-parts /etc/cron.daily&quot; to be run. The command run-parts checks a directory for files that are executable by the user specified in the user field. It runs all of them, in some kind of order This is a good way of getting a lot of small things done without writing a big script. Makes it a lot easier maintaining the jobs. My /etc/cron.daily have the following files: calendar* standard* sysklogd* find* man* netbase* smail*
tetex-bin*

So every morning at 05:44 my computer starts doing things like rotating my logs, updating the manual index files, updating the updatedb database and other things that is quite good if you do once a day. At 05:44 I usually don't use my computer anyway (I do actually sleep sometimes ! ) so these jobs don't use any CPU - time I could need.

The other lines work just as the first, executing things every week and every month. There is a user field, if you put another user than root there, it will run the command with other rights than root. That is often recommendable by security reasons.

The per - user crontab
Every user on the system may write his own crontab. The job will be executed even though the user is not logged on. The format is similar to the system crontab, though there is not user field, since a user's cron commands will always be executed as that user. My personal crontab looks like this: 10 5 * * 0 futility tool &quot;+delete&quot; &quot;keep+1300&quot; ; futility pack
5 3 * * * /home/erik/bin/mirroring
15 0-23/1 * * * /usr/bin/fscan

As you can see, it has three jobs. The first one goes every Sunday (Day of week field has the value 0, which is Sunday. I could write 'Sun' there too) and does some packing of my fidonet message base.

The second goes every day at 5 minutes past 3 in the morning and mirrors some ftp archives.

The third executes 5 minutes past every hour 24 hours a day. The syntax 0-23/1 tells cron it should do it once an hour from hour 0 to hour 23. 0-14/2 would mean twice an hour from 00:00 to 14:00 in the afternoon.

The crontab command
When a user wants his own crontab, he has to install it. This is done with the command crontab. The syntax is quite simple, crontab name-of-crontab will install the file you specified as your new crontab. The command crontab has some other switches, to list, edit or remove crontabs, but the basic syntax is actually all you need to know - If you want to edit you crontab, do so and reinstall it with a new crontab command.

Environment variables and file rights.
There are a few things one should think of when trying to master cron. First cron doesn't read your login files to set the path you're used to, so a command that executes just fine when you test it may not run at all because cron can't find some file. There are two solutions to this problem, the first is to use only absolute filenames (ie give the whole path to the files), the second to include something like PATH = /usr/local/bin:/home/foo/bar

in your crontab. That way you set the environment variable PATH, so your scripts will find the files.

Another environment variable of interest is MAILTO. If you set that variable (the same way as you set PATH) cron will mail the output of your commands to the address specified. Cron will by default mail the output to the user the crontab belongs to, but if you want the mail to go somewhere else you may specify it in the variable. You may also give an empty MAILTO variable (by writing &quot;MAILTO=&quot; in your crontab). Cron won't mail any mails to an empty address..

File rights can sometimes be a problem. If cron doesn't want to execute your scripts or programs, try giving the group or world execution rights to the file. That may solve the problem. The irritating thing is cron won't tell you it can't execute, it just sits there doing nothing.
<END SNIP>