Submitting cron in Unixware - error permission denied 2

[vistech1]

A customer of mine is having problems submitting cron jobs as other users (root works fine).

Unixware 7.1.3

They have a user "support"

When support user submits its cron:

in support's home diretory is a file called support.cron

-rwxrwxrwx 1 support support 126 May 12 2004 support.cron

when I vi the file:

51 9 * * * /directory_to_script/sysdate.sh
15 3 * * 1-5 /directory_to_script/chkledgr.sh

I then submit the cron as user support

support: crontab support.cron
UX:crontab: ERROR: Cannot open message queue: Permission denied
UX:crontab: WARNING: Commands will be executed using /usr/bin/sh

I checked thread 755210, but this dealt with the problem on OpenServer and I did not see a -h option in custom for Unixware.

Any ideas would be appreciated.


Thanks!

 

[PHV]

In the cron man page pay attention to allow and deny.

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[vistech1]

I should have mentioned that I read the man page on crontab prior to posting.

This is what I had found.

allow and deny files

Users can use crontab if their names appear in the file /etc/cron.d/cron.allow. If that file does not exist, the file /etc/cron.d/cron.deny is checked to determine if the user should be denied access to crontab. If neither file exists, only root can submit a job. If cron.allow does not exist and cron.deny exists but is empty, global usage is permitted. The allow and deny files consist of one user name per line.

I checked the server and verified that in /etc/cron.d that cron.allow does exist and cron.deny does not exist.

# ls -l
total 20
-rw-r--r-- 1 bin bin 35 Mar 8 2004 at.allow
-rw-r--r-- 1 bin bin 47 Nov 23 17:09 cron.allow
-rw-rw---- 1 root sys 0 Feb 7 23:25 LCK_CRON
lrwxrwxrwx 1 root sys 13 Mar 4 2004 log -> /var/cron/log
prw-rw---- 1 root root 0 Dec 30 16:54 NPIPE
-rw------- 1 root sys 44 Apr 23 2004 pwd
-rw-r--r-- 1 bin bin 17 Oct 31 2002 queuedefs
-rw-r--r-- 1 root sys 866 Apr 23 2004 root.job

# cat cron.allow
root
sys
adm
uucp
lp
informix
support
rjlt
rjm

shows user "support" in cron.allow and cron.deny doesn't exist.

So in theory, because user support is in the cron.allow file and there is no cron.deny file, user support should be able to create and run it's cron jobs, no?

 

[vistech1]

I discovered that the problem was with permissions on the NPIPE file. I throughly checked and rechecked the man pages on cron (specifically paying attention to allow and deny) but did not see where the configuration on the customer server was different than was implied in the man page).

The file /etc/cron.d/NPIPE was:
prw-rw---- 1 root root 0 Dec 30 16:54 NPIPE

Needed to be changed to:
prw-rw---- 1 root sys 0 Dec 30 16:54 NPIPE

Once I made this change I was able to submit the crons with no error messages and the cron ran as expected.

 

[vistech1]

I discovered that the problem was with group ownership on the NPIPE file. I throughly checked and rechecked the man pages on cron (specifically paying attention to allow and deny) but did not see where the configuration on the customer server was different than was implied in the man page).

The file /etc/cron.d/NPIPE was:
prw-rw---- 1 root root 0 Dec 30 16:54 NPIPE

Needed to be changed to:
prw-rw---- 1 root sys 0 Dec 30 16:54 NPIPE

Once I made this change I was able to submit the crons with no error messages and the cron ran as expected.

 

[KenCunningham]

A star for posting back with the solution!

 

[vistech1]

Customer called and was having "cron" problems again.

found that the permissions on usr/sbin/cron was 777 and needed to be changed to 2550.