Cron job won't work. v25.0.4. Really struggling here

I’m struggling very much to get Nextcloud to use crontab based background jobs, to the point where I must ask for some help/advice. I’m already beyond my regular knowledge level on Linux/Nextcloud.

When I set my Nextcloud instance to use Cron for background jobs, Nextcloud always tells me that no background job has been performed for the last xx minutes/hours. AJAX appears to work though.

My Nextcloud 25.0.4 installation is pretty brand new (no VM or Snap, but manual installation), as is my Linux Ubuntu Server 22.10 installation.

As part of my NC installation, I did implement a cron job every 5 minutes, by entering …

sudo crontab -u www-data -e

… and editing the cron in VI. I added the recommended …

*/5 * * * * php -f /var/www/nextcloud/cron.php

… code at the bottom of the Cron and saved it. The address to my cron.php file in the code is correct.

This didn’t work, Nextcloud web interface tells me no background jobs are performed when Cron is selected.

So I researched out that the code “PHP” (in the code above) may actually point to a different PHP version than Nextcloud uses (v8.1 in my case), if I – by some chance – have several different PHP versions on my system.

Informed by the discussion in this thread, I ran …

sudo update-alternatives –config php

… and was presented with a menu of 3 different PHP implementations, and could choose which one the system is to regard as the default one. I selected the right one, and the prompt confirmed that PHP v8.1 was now regarded as system default.

Still no improvement in Cron job deficiency.

So I tried reformatting the code in the crontab, trying …

*/5 * * * * php8.1 -f /var/www/nextcloud/cron.php
*/5 * * * * php -f /var/www/nextcloud/cron.php
*/5 * * * * php-cli -f /var/www/nextcloud/cron.php
*/5 * * * * /usr/bin/php -f /var/www/nextcloud/cron.php
*/5 * * * * /usr/bin/php8.1 -f /var/www/nextcloud/cron.php

I restarted the machine every time I changed it (just to be sure the adjustment was fully implemented right away). Still no luck. :frowning:

Btw I’m using the Nextcloud web interface, administrator settings to check however Cron has done some background job or not. Currently I’m running Ajax, and it appears to work.

I do remember though, that when I first created the crontab, during my installation process, I was told – by the manual I was using at the time – that not only must the user be “www-data”, but this user was supposedly also a part if a ‘Group’ called www-data too (?) So therefore, the manual said, instructed me to create the cron job by entering both user and usergroup. Like so:

Sudo crontab -u www-data:www-data -e

When I adjusted the code between different PHP versions and options (see above) I did not however use the term www-data:www-data, but simply www-data. When I check for existing cronjobs for the user www-data, my cron job is listed there, with the code I entered in. So it is correct so far. But might I have corrupted something by adding the user-group to the command as well?

With this, I’m at an end of what I have researched out so far, but I still feel it should work with this. What I have now are a few suspicions and loose ends, to offer for errorsearching.

Hints of further errors?
For example, whenever I enter into the administrator settings in the Nextcloud web interface, and I have AJAX selected, the web interface always says the last background job was performed “seconds ago”. It never says “was performed 4 minutes ago”, or 1 minute, or 2 minutes. It is ALWAYS “just seconds ago”.
This gives me the impression that the AJAX background job is performed BECAUSE I enter into the administrator settings in the web interface, since it is ALWAYS just seconds ago.
I’m not sure if I’m being paranoid here, but … it doesn’t feel right. Might this be an indication of something wrong that could be part of why also the cron appears funky? I’m just fishing here.

NC Errorlogs
I also looked into the errorlog in the Nextcloud web interface, and I was able to spot some potentially relevant errormessages there. It seems that each time I selected Cron as the background job type, just to see if it by any chance just suddenly pop started working or turned on, it seems Nextcloud wrote many errorlogs during those specific time periods. In particular this one, which there are many of:

[files_antivirus] Error: OCP\Files\NotPermittedException: at <>
0. /var/www/nextcloud/apps/files_antivirus/lib/Item.php line 185

  1. /var/www/nextcloud/apps/files_antivirus/lib/Item.php line 75
  2. /var/www/nextcloud/apps/files_antivirus/lib/Scanner/ScannerBase.php line 89
  3. /var/www/nextcloud/apps/files_antivirus/lib/BackgroundJob/BackgroundScanner.php line 313
  4. /var/www/nextcloud/apps/files_antivirus/lib/BackgroundJob/BackgroundScanner.php line 110
  5. /var/www/nextcloud/lib/public/BackgroundJob/Job.php line 78
  6. /var/www/nextcloud/lib/public/BackgroundJob/TimedJob.php line 103
  7. /var/www/nextcloud/lib/public/BackgroundJob/TimedJob.php line 93
  8. /var/www/nextcloud/cron.php line 177
    GET /cron.php
    from at 2023-03-05T18:13:55+00:00

I do have ClamAV installed, and I call on it from Nextcloud web interface by “ClamAV Executable” in /usr/bin/clamscan using “ICAP preset: ClamAV”.

Apps interfering?
I also have quite a few Nextcloud Apps already installed, and I am thinking that perhaps one of those could interfere with the Cron job execution? If anyone knows …?

Manually triggering Cron job
I was just asked to try the following Linux command …

sudo -u www-data php8.1 -f /var/www/nextcloud/cron.php

… and the response was a somewhat interesting …

OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

I seem to recall having the ACPu included in the installation process of Nextcloud, and I do have this line in config.php …

‘memcache.local’ => ‘\OC\Memcache\APCu’,

… but if someone knows how to re-check/verify that ACPu is operational or not, I’m all up for it.

A longshot: spelling error in code?
I also spotted this thread, which claims a similar problem, and addresses a simple spelling error in a line of code to be the culprit. But I’m not sure where to look for this code line(?) It’s not in my config.php.

Thank so much in advance for any idea or comments, to take this problem further towards a solution.

RIght nbow you try to modify www-data as the user crontab

sudo -u www-data crontab -e

Okay so this verifies that:

You have PATH env set correctly.

It tries to execute the cron.php.

There are a few hickups we needs to look at though.
If you have followed the recommended setup guide, you are running Nextcloud under php-fpm. If this is true, you have more than one .ini file to be aware of.
For CLI php you are NOT using the same settings and configs as nextcloud webservice, when calling the PHP module natively from CLI. So first you needs to verify that you have enabled CLI of the PHP8.1 application, and secondly that you have enabled all the needed modules in THAT one as well.

That is wrong and not a helpful comment, crontab is not a user but a command.
Refer to man crontab

@Ange.Reid :
Did you add to /etc/cron.allow

If not, there exists a file:


which is the only systemwide crontab for use with multiple users.

Instead of Vixie Cron, try that one.

Add this line to /etc/crontab

*/5  *       *       *       *       www-data        php -f /var/www/nextcloud/cron.php

You can find out which php is effectively in use with:

readlink $(which php) | xargs readlink -f

Funny you say that it is wrong, and instead advices him to go advanced and intermingled instead of Nextcloud recommended and seperated. Have you read what he actually wrote?

sudo -u crontab www-data -e

and NOT

sudo -u www-data crontab -e

Hence my comment is accurate.
You CAN use this instead

sudo crontab -u www-data -e

SImply create a specific cron for the www-data user - which is also the Nextcloud recommended approach. No need to start messing around with the main crontab config instead of keeping things truly seperated. In fact it is highly advised to do that, as you do not risk deleting/changing cron commands for other users and services by accident.

No. Re read his Post.

He wrote it correct:

Yes. That he did. My bad. I read it wrong. Next beer is on me. Cheers mate.

Back on topic:
It does not seem that there is anything wrong with your cron job. It seems the issue is in your PHP configs.

Just for the record, I didn’t follow THE manual, assuming you meant straight off of the Nextcloud text manual. I didn’t know I could do that. I used a highly recommended 1 hour youtube video, and it seems to have worked all the way up to this point.

And CLI, I just threw that in there in the blind, to test. I got the idea off of the Nextcloud manual, which says “On some systems it might be required to call php-cli instead of php .”
Bit It didn’t cause any change in functionality that I could tell.
I am not aware if I am using a CLI funktionality or not. I’m not quite that knowledgeable - yet. So far I’m just really stubborn.

So, I will try to figure out how to verify that I have installed and enabled the CLI of the PHP8.1 application, as well as its dependencies - whichever they might be.

I do like beer though :sunglasses:

Where does the certainty come from, if you don’t know if he is using a
file. There is also the possibility that the crontab file was not terminated with a blank line, which is mandatory for crontab files.

And last but not least, is the cron daemon up and running?

systemctl status cron

All understood. Found the /etc/crontab file and added the line you suggested to it and saved it. Is this what “adding www-data to /etc/cron.allow” means? or did I miss something?

PHP8.1 is the one effectively in use …

Yes the Cron daemon shows installed and enabled. (loaded: /lib/systemd/system/cron.service; enabled; preset; enabled. Active and running).

Did I just start an argument in the thread? Man, I’m so horrible :face_with_open_eyes_and_hand_over_mouth:

I will give you the benefit of the doubt and say that I verify that according to the odds of where this can or could go wrong. After all he did get an error - from PHP and from the Nextcloud cron.php - when he manually executed the cron.php. So I takes my chances that it will be fixed for him when he has sorted out those.

1 Like

This one - however - should be added to the docs under setting up cron for nextcloud. And then a section about memory settings and to enable/add the same module as added when implementing using fpm as well.

Try to simply not use memcache for now. You said it was brand new, so try commentblock the memcache config in config.php, restart php-fpm (if using that) and apache2 or NGINX or whichever webserver you use, and execute the cron.php manually again.

[quote=“Kerasit, post:13, topic:157175, full:true”]
Try to simply not use memcache for now. You said it was brand new, so try commentblock the memcache config in config.php, restart php-fpm (if using that) and apache2 or NGINX or whichever webserver you use, and execute the cron.php manually again.[/quote]
Right. Memcache taken out of config.php, Apache2 restarted, I don’t think I got- or am utilizing php-fpm. Manual execution of cron.php didn’t give a response back in the prompt (contrary to last time). Just a new line break in the prompt. I hope this means a good thing? :slight_smile:

Yes it is a good thing. :slight_smile:

Now with that still blocked out, keep your cron setting, setup cron in NC to use system cron, wait to see if it runs.

If it does, well we needs to look at your CLI settings.

Ok. Just so I don’t misunderstand: “setup cron in NC to use system cron” … means open up Nextcloud web interface, go to admin settings and change from AJAX (which I got now) to Cron, and wait a few minutes?

Should it work, with memcache taken out? Hm. I’m taking notes here, because I want to learn from this. :slight_smile:

Christ, I can’t even manage to get the QUOTE code in the forum right? :disguised_face:
EDIT: ok, there … at least I got THAT part right.

It will work, but for performance, you definately needs caching.

Yes. :slight_smile:

Not quite but /etc/cron.allow is not the problem since it is not present.

The only thing left I think is possible would be a missing newline at the end of the crontab.

You could open a second window, switch loglevel to 0 and follow the log output while you are executing cron.php:

occ config:system:set loglevel --value=0
occ log:tail --follow

run cron.php in other terminal

switch back loglevel:

occ  config:system:set loglevel --value=2

Maybe you find some helpfull echoes

In the crontab textfile, I entered the */5 * * etc line immediately beneath the commented out instruction text. You’re saying it’s not a total impossibility that I didn’t put a line break before it? Hm. I’ll keep that in mind for now.
What I do know is the commented out instruction text in the crontab file was dark blue in color, and the code I write on was colored clearly different purple (Using VI editor). But who knows. I’m just taking in everything I hear now. I’m really very grateful for this attention, gentlemen :slight_smile: