# vixie-cron - cron permission denied [solved]

## Aphex3K

Hey Folks,

ive got a strange problem. I'm running Gentoo on a virtual server where it has been isntalled and now i can use it as rootserver. It works pretty well but i've got a cron problem.

No matter wether the jobs are in users crontab (crontab -e) or in /etc/cron.[daily|weekly|...]/ by the time when a job should run i get permission denied in syslog and thats it. For example:

 *Quote:*   

> Aug  3 11:30:01 vtux cron[17384]: Permission denied
> 
> Aug  3 11:35:01 vtux cron[17390]: Permission denied

 

(vtux 's the name of the box)

Anybody any suggestion? I've got a cron-user, a cron group, everything seems allright. I've emerged vixie-cron(vixie-cron-4.1-r7) several times. nothing helped at all...  :Sad: 

----------

## Aphex3K

anybody?

----------

## m_sqrd

what are the permissions on /etc/crontab ?

should be 0600

----------

## Aphex3K

 *m_sqrd wrote:*   

> what are the permissions on /etc/crontab ?
> 
> should be 0600

 

```
vtux ~ # ls -l /etc/crontab

-rw-------  1 root root 621 Aug  1 08:43 /etc/crontab
```

It is

----------

## Aphex3K

anything else i could check?

----------

## dev-urandom

Its highly unlikely, but you are running crond as root right?

----------

## Aphex3K

 *dev-urandom wrote:*   

> Its highly unlikely, but you are running crond as root right?

 

```
root     19028     1  0 07:06 ?        00:00:00 /usr/sbin/cron
```

Looks like...

----------

## dev-urandom

 *Aphex3K wrote:*   

>  *dev-urandom wrote:*   Its highly unlikely, but you are running crond as root right? 
> 
> ```
> root     19028     1  0 07:06 ?        00:00:00 /usr/sbin/cron
> ```
> ...

 

That is fine.  Its running the way it should.

What are the settings in /etc/pam.d/cron ?

I hope there is no line 

```

account sufficient pam_deny.so

auth sufficient pam_deny.so
```

Better still, can you post the output of the file here?

Also what are the directory/file settings inside /var/spool/cron ?

You haven't used chattr here have you?

----------

## Aphex3K

```
vtux ~ # cat /etc/pam.d/cron

#%PAM-1.0

account required        pam_unix.so

auth    required        pam_unix.so

session required        pam_limits.so
```

```
vtux ~ # ls -l /var/spool/cron/

total 8

drwxr-x---  2 root cron 4096 Aug  2 21:30 crontabs

drwxr-x---  2 root cron 4096 Aug  2 16:17 lastrun

vtux ~ # ls -l /var/spool/cron/*

/var/spool/cron/crontabs:

total 8

-rw-------  1 root root 1450 Jul 31 19:49 mailman

-rw-------  1 root root  505 Aug  2 21:30 root

/var/spool/cron/lastrun:

total 0

-rw-r--r--  1 root root 0 Aug  2 16:17 cron.daily

-rw-r--r--  1 root root 0 Aug  2 16:17 cron.hourly

-rw-r--r--  1 root root 0 Aug  2 16:17 cron.monthly

-rw-r--r--  1 root root 0 Aug  2 16:17 cron.weekly
```

chattr? Not that i know of. I might have used chmod or chown in a humbly strike to solve the problem on my own...

----------

## Aphex3K

Is it wrong or right? Should the cron user/group be involved somewhere there?

----------

## magic919

I use vixie-cron and can't see any difference between your set-up and mine.  Can you clarify whether this affects all crontabs?  Or does it work for root and fail for users??

T

----------

## Aphex3K

It fails for root at least and i didnt try another user...

----------

## magic919

```
denzil2 ~ # ls -la /etc/crontab

-rw-r--r--  1 root root 616 Jul 25 17:24 /etc/crontab

```

Checked this on a couple of mine and both the same.  

I notice your logs don't give the name of the user for the crontab.  Mine do, but I can't find anything to help solve.

I'd be tempted to unmerge, nuke every file and directory for Cron and start again.

----------

## Aphex3K

```
# /etc/init.d/vixie-cron stop

   ...

# rc-update del vixie-cron

   ...

# userdel cron

# groupdel cron

# rm -r /etc/cron*

# rm -r /var/spool/cron*

# groupadd cron

# useradd -g cron cron

# emerge vixie-cron

   ...

# rc-update add vixie-cron default

   ...

# /etc/init.d/vixie-cron start

   ...
```

That seems to do the trick...

----------

## magic919

It's a bit of a sledgehammer approach but there was no clear trace of anything wrong, it just didn't work.  Glad it worked out.

----------

