What’s your host system?
the host is running ubutu LTS
Maybe you should. They have a Dockerfile for doing this, and with docker-compose, the process is basically automatic.
i just run them as cron jobs on the host. put them in small skript
/usr/local/bin/nextcloud_optimize.sh and put this roots crontab.
any reason for this?
did you try to copy the cron.sh to your host, add your tasks and run the container like this:
as far as i can tell the crontab entry is done here. So as you can see, inside the container the file
/var/spool/cron/crontabs/www-data is used and it usually contains one line like
*/5 * * * * php -f /var/www/html/cron.php for executing the
cron.php every 5 minutes. If you want to do any additional cron tasks you could mount a custom crontab file and add any desired lines. A snippet of the corresponding
docker-compose file could look like this:
while the content of
mycronfile could be something like
*/5 * * * * php -f /var/www/html/cron.php
0 0 * * 0 php -f /var/www/html/occ fulltextsearch:index
which will additionally index your NC instance once a week on sunday night at 0:00.
could you please show an example on how to add a task to this script?
I could not find any examples on how to use this cron.sh. It seems to be a normal bash script but then how do you add a task e.g. for preview generator (
occ preview:pre-generate)? I do not understand the “exec busybox crond” line already in that file, why do you need exec?
Thanks in advance!
use this script as cronjob. do not try to enable cron inside the contaier. inside any container.
so you just add
docker exec --user www-data nextcloud php occ preview:pre-generate assuming that your container name is nextcloud and www-data the web server user.
this is a way to enable crond inside a container.
exec executes everything you use as the first argument. e.g. a shell skript has no +x bit.
exec that-skript is your friend. and
busybox crond just starts the cron daemon inside the container.
nevertheless after i wrote the comment above i found this article in german Projekt Rootserver - geschlossen it says: don’t do it with busybox. not a good idea. the authors advice: use the host cron + docker exec
Thanks @Reiner_Nippes. I will then use system cron. I use this docker-compose config to run my nextcloud and since there is a docker service for cron I thought I should use that but then that’s not recommended.
I just migrated my nextcloud to a docker setup on a NAS as host system. First I used the second container solution but now switched to your proposal of using a script in the host’s cron service.
Yet I have two questions that maybe you or s.o. else have answers to:
- Do these commands
docker exec --user www-data nextcloud php occ files:scan --all docker exec --user www-data nextcloud php occ files:scan-app-data docker exec --user www-data nextcloud php occ preview:pre-generate exit 0
represent all relevant jobs which are usually done by cron.php?
- Does this solution have any advantage against for example calling cron.php as a webjob like e.g. https://zeitfresser.net/nextcloud-cronjob-ueber-synology-erstellen/ (de) proposes?
Oh, and a bonus question if I may:
- It is a tiny setup for max 5 users mainly using the cloud during daytime. So I’d like to let my NAS sleep during nighttime. A 24/7 every-15-minutes cronjob would prevent this, right? Is there any risk if I pause the cronjob during night hours ?
yesterday I was fixing my cron job, cos my deployment is running in docker-compose statement, so yes, as you said, I created a cronjob into the host to call a simple:
docker exec -t -u www-data nextcloud-app php -f /var/www/html/cron.php
in fact, from my beginner understanding from all about containers, It should be better run it on this mode. We should leaves each container running its own service.
Sorry to dig the topic up, but I recently had conflicts with cron tasks: can anyone please confirm that the above cronjob
docker exec -t -u www-data nextcloud-app php -f /var/www/html/cron.php is created for the www-data user (
crontab -u www-data -e) and not for the root user?
Thanks in advance for your help!
should run as root on the docker host. or any user that is a member of the group “docker” on the host.
regarding the cron.php my user www-data is the owner, hence you should run it as Reiner said or by the owner/group member.
I created/updated the crontab for the “root” user according to your advice:
30 1 * * * docker exec -t -u www-data php -f cron.php
and still get the (translated from French) “the last cron task ran 5 days ago. Something went wrong. […]”.
Is there any way to get only the cron log from the container?
Thanks in advance for your help!
@jlgarnier: if you run cron from the host, you won’t have the cron log in the container, but the result of the command should be visible using
docker logs, since cron.sh uses /dev/stdout.
But I don’t understand why this isn’t ‘fixed’ in some way:
- The default is AJAX, which is the ‘least reliable’ according to the documentation (why is this the default, then?)
- In the basic settings I can select cron, but this won’t activate cron (why make it an option there? Does this do anything?)
- The preferred solution, when using Docker, is to use crontab on the host (doesn’t this defy the point of Docker? What’s the problem with using cron in a container?)
I fully agree and did the same analysis: why is Ajax the default setting and why doesn’t the Cron option just set the appropriate crontab?
By the way, I think the cron working was disturbed by the ‘listman’ plugin, which was looking for an unknown file and crashed during the task… I’ve disabled the plugin, hope this will fix the whole stuff!
Thanks again all for your help!
Is it still the case that this approach is not recommended? It seems to be the suggested approach in the official NextCloud docker repo.
@norsemangrey I can’t tell you. But since it is “Nextcloud Offical” it can’t be wrong.
You can use the docker host’s cron to invoke cron.php in the container every 5 minutes. Simple and effective. I’ve done this on several of my installations and never had a problem with it.
I’ve used the official supervisord setup too and that also works.
take a look at this post and thread. you just need to persist the file
/var/www/html/cron.php and adopt according your needs… enjoy the official cron container!