I have two nextcloud instances running in virtualmin virtual hosts.
For bot I have a scheduled cron job to trigger my nextcloud instance to check for changes.
For one it works fine. It was installed “centuries ago” several updates and upgrades, like webmin/virtualmin.
The other I installed today, works flawlessly but for this.
The exact same scheduled cron job for the new one just won’t fire… nothing happens, nothing in the logs either… job is a clone of the one of the “old” instance.
Now I had the admin user account named user_name (with underscore).
I read that in the past that could have been an issue…
I redid all and now chose user-name (with minus)…
It has the same issue… so my guess, that isn’t the problem…
Maybe that cron isnt running at all, that would explain why nothing in the logs. Did you try to set some simple task with cron and see if is running at all. For this you can pick any example you find on google and try it.
Another thing, did you check root email and see if there is something what could explain why cron isnt executing?
this is a webmin/virtualmin setup so by default there are several cron jobs already. Also there are jobs for my other nextcloud vhost that does run OK from cron…
like there are also scheduled cron jobs I have on a few other web apps (phpservermonitor and an app of myself updating my dynamic DNS to cloudflare)… all do work ok…
though cron log shows empty by all means…
this is a webmin/virtualmin setup so by default there are several cron jobs already. Also there are jobs for my other nextcloud vhost that does run OK from cron…
like there are also scheduled cron jobs I have on a few other web apps (phpservermonitor and an app of myself updating my dynamic DNS to cloudflare)… all do work ok…
though cron log shows empty by all means…
I opened the “existing for ages” /var/spool/cron/crontabs/oldone and /var/spool/cron/crontabs/newone.
I noticed that in the new job, the spaces where replaced by tabs:
These tabs are “created” by creating a scheduled cron in the webmin interface. The old one works the new one does not. Replacing tabs for spaces doesn’t do anything… but there is some difference…
I did what you asked. There is nothing mentioned in the mailboxes in root on these jobs…
I checked /var/log/syslog for “cron” all show at their time schedulen but the newone… as if the /var/spool/cron/crontabs/newone isn’t picked up…
I think I found it…
The ownership of “/var/spool/cron/crontabs/newone” was root:root instead of newone:crontab like the others in the folder.
Permissions where set a 644 instead of 600 like the others.
Odd is:
The scheduled cron job is created in the exact same way as the previous ones… I cannot see any reason why these settings would be root:root 644 whereas the other jobs where set ok in the past…
I now made the changes and that seems to do it… the job is running as scheduled.
Creating a new cron job should follow user:crontab (in this case newone:crontab) permissions 600 instead of root:root 644 right?
Can I make settings somewhere to ensure that behaviour? Or is this a bug?
Odd is: The scheduled cron job is created in the exact same way as the previous ones… I cannot see any reason why these settings would be root:root 644 whereas the other jobs where set ok in the past…
You can file a bug report and just post a link to this topic. If there is bug it would be good for devs to know about this problem.
