I'm not sure when things changed. I'm currently running vixie-cron-4.1-r10. As a regular user I've been able to use the crontab command for a long time (I'm in the cron group). My user's crontab is executing still, but I cannot access it: $ crontab -l cannot chdir(/var/spool/cron), bailing out. /var/spool/cron: Permission denied or change it:$ crontab ~/.crontab cannot chdir(/var/spool/cron), bailing out. /var/spool/cron: Permission denied $ ls -ld /var/spool/cron 4.0K drwx--x--- 4 root root 4.0K 2007-06-23 08:24 /var/spool/cron/ Re-emerging cron-base (0.3.2) and vixie-cron did not solve the problem. I'm not certain which version of which this behavior changed as I rarely need to mess with my user crontab, but I'm pretty certain that it *used* to work.
This is by design and intended, read the postinst message and see Bug 164466. Add yourself to crontab group if you need to edit crontabs.
(In reply to comment #1) > This is by design and intended, read the postinst message and see Bug 164466. > Add yourself to crontab group if you need to edit crontabs. > I don't entirely understand the bug report or what else I need to do. The postinst message seems to indicate that it reset some permissions in /var/spool/cron/crontabs. It also points to a web page. Neither the postinst nor the web page make mention of the crontab group. Nevertheless, I added the user to the crontab group. but I still can't edit/list my crontab. drwx--x--- 4 root root 4096 2007-06-23 11:37 /var/spool/cron It seems that the crontab command wants to chdir here, but only root can do that. I did not set the perms on this directory. Apparently it's being done by cronbase when it installs. Do I need to change the permissions and if so what need it be changed to? vixie-cron sets /usr/bin/crontab up as such: -rwxr-s--x 1 root crontab 29K 2007-06-23 11:40 /usr/bin/crontab
(In reply to comment #2) > drwx--x--- 4 root root 4096 2007-06-23 11:37 /var/spool/cron > > It seems that the crontab command wants to chdir here, but only root can do > that. I did not set the perms on this directory. Apparently it's being done by > cronbase when it installs. Do I need to change the permissions and if so what > need it be changed to? No idea how you ended up with that; it's supposed to be 0750 root:cron, as every single sys-process/cronbase ebuild suggests. diropts -m0750 -o root -g cron; keepdir /var/spool/cron Portage won't change it on re-emerge, see Bug 141619, so you'll have to fix it manually. *** This bug has been marked as a duplicate of bug 141619 ***
(In reply to comment #3) > > No idea how you ended up with that; it's supposed to be 0750 root:cron, as > every single sys-process/cronbase ebuild suggests. > > diropts -m0750 -o root -g cron; keepdir /var/spool/cron I know I'm probably annoying you, but one more question... should that truly be root:cron? I checked 9 other Gentoo systems and they're all cron:root. I just want to be sure before I change it on all those systems and have them all break. I don't know how my other box got to be root:root. It is my oldest Gentoo system, so perhaps those were set a long time ago and never got changed.
(In reply to comment #4) > I know I'm probably annoying you, but one more question... should that truly be > root:cron? Well, as quoted above, yeah it's really supposed to be like that... diropts -m0750 -o root -g cron man install -g, --group=GROUP set group ownership, instead of process' current group -o, --owner=OWNER set ownership (super-user only)
I think that this is happening again
I think that this is happening again(In reply to comment #6) > I think that this is happening again > sorry my bad.. I got to add my user to cron group. Sorry to have bothered you.
