Unix "crontab -e" command 1

[rawebley]

This incident has suddenly started to occur.
If you log into the unix prompt as a user other than "root", issuing the command "crontab -e" and then saving the file results in the following error occuring:
"crontab: error in message queue open: Permission denied (error 13)"

richard.webley@kenure.co.uk

 

[pmcmicha]

What is the OS version?

Also have you tried the following to see what happens?

1) crontab -l > xxx.cron # Where xxx is the user name.
2) vi xxx.cron, edit, save.
3) crontab xxx.cron

Do you get an error message here as well?

 

[rawebley]

Yeah, I have tried this but unfortunately it doesn't work. Thanks for the help anyway!

Richard

 

[rawebley]

Sorry I forgot to mention - the version is "Release = 3.2v5.0.6"

 

[pmcmicha]

Well, do you have the following patch installed?

(SLS) OSS642A

Also, what logs have you checked? Does the directory where your crontabs are located look okay, no hidden files, files are not corrupt?

You also might want to check /usr/lib/cron and verify that these files are okay as well.

 

[apeasecpc]

Is this a new user you have just set up and are trying for the first time, or is it an old user that was previously able to set up cron jobs?

It sounds like a permissions problem to me.

log in as root and check the permissions of the directory structure where the crontabs are stored.

/usr should be:
drwxrwxr-x 26 root auth

/usr/spool should be:
drwxrwxr-x 15 root bin

/usr/spool/cron should be:
dr-xr-x--- 4 bin cron

/usr/spool/cron/crontabs should be:
drwxrwx--- 2 bin cron

In the /usr/spool/cron/crontabs there will be a file with the same name as the user the cron is set up for. If there is no file by that name then your crontab for that user was never set up or has been erased. If the file does exist make sure the owner is the same as the file name (but don't change ownership of any of the files for system users such as mmdf, root, or uucp). The user's crontab permissions should be:
-rw-rw---- 1 {user-name} cron

If all of the permissions look good, log in as the user and try to view the contents of the crontab file:
more /usr/spool/cron/crontabs/{user-name}

If the problem still is not resolved, remove the file from /usr/spool/cron/crontabs (after making a backup of it), shutdown and restart, then try to set up the cron again.

If the problem still is not resolved, do an OS verify from custom.

 

[rawebley]

Cheers my man. I checked the permissions on the respective "cron" directories which seemed correct. I then ran the command "custom -h xxxxxxxxx" where xxxxxxxxx is the machine name and this fixed the problem. It also fixed a number of other problems.

Thanks

 

[vistech1]

A customer of mine is having the same problems except this is on a Unixware v7.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 did not see a -h option in custom for Unixware.

Any ideas would be appreciated.

Thanks!