Les notifications arrivent en retard, les flux RSS ne se mettent plus à jour ou une analyse reste en attente ? En 2026, le cron Nextcloud est le mécanisme recommandé pour exécuter régulièrement les tâches d’arrière-plan d’une instance. Il déclenche cron.php toutes les cinq minutes, sans dépendre de l’ouverture d’une page par un utilisateur.
Ce guide explique le rôle de la file de travaux, les différences entre AJAX, Webcron et cron système, puis fournit une configuration pour Linux et Docker. Il couvre aussi la fenêtre de maintenance et une méthode de diagnostic lorsque le dernier passage n’avance plus.
À quoi servent les tâches d’arrière-plan Nextcloud ?
Nextcloud sépare les actions immédiates des traitements qui peuvent être exécutés plus tard. Une application enregistre un travail dans la base, puis le mécanisme de fond lance les éléments devenus éligibles. Cette organisation évite de faire attendre le navigateur pendant une opération différée et répartit les traitements dans le temps.
Le guide complet de Nextcloud présente les applications principales. Plusieurs d’entre elles dépendent directement d’un passage régulier. Le lecteur Nextcloud News relève les flux par un job dédié. Le scanner de l’antivirus Nextcloud avec ClamAV utilise aussi les tâches de fond pour examiner des fichiers existants.
La documentation développeur distingue plusieurs types de travaux. Un job simple attend le prochain passage disponible. Un job temporisé ne devient exécutable qu’après son intervalle. Un job classé non urgent peut être réservé à la fenêtre de maintenance afin d’éviter les heures d’activité habituelles. L’application qui crée le travail définit ce comportement, pas l’entrée crontab elle-même.
Un cron actif ne garantit donc pas que chaque tâche réussit. Il fournit des occasions d’exécution régulières. Une application incompatible, un stockage indisponible, une erreur PHP ou une base saturée peut encore interrompre un traitement. Il faut surveiller à la fois la dernière exécution générale et les erreurs propres à l’application concernée.
Cron déclenche la file, il ne remplace pas la supervision
Une date de dernier passage récente confirme que cron.php a été lancé. Elle ne prouve pas que tous les travaux ont terminé sans erreur. Contrôlez aussi les journaux et le résultat fonctionnel attendu.
Quelle différence entre AJAX, Webcron et cron système ?
Nextcloud propose trois méthodes dans Paramètres d’administration, puis Paramètres de base. AJAX est sélectionné par défaut sur une nouvelle installation. Il tente d’exécuter un travail à la fin d’une requête de page, avec une fréquence maximale de cinq minutes. Si personne n’utilise l’interface, les tâches ne démarrent pas régulièrement.
Webcron appelle cron.php depuis un service HTTP externe. Le service doit ouvrir l’adresse toutes les cinq minutes. Ce mode peut dépanner un hébergement qui n’autorise aucune tâche système, mais Nextcloud le décrit comme moins fiable que cron. Il dépend du réseau, du service externe et de l’accès web à l’URL.
Le cron système exécute directement le fichier PHP côté serveur. C’est la méthode recommandée par Nextcloud, car elle fonctionne même sans session active et ne dépend pas d’un prestataire de Webcron.
| Méthode | Déclenchement | Usage adapté | Limite principale |
|---|---|---|---|
| AJAX | Chargement d’une page | Test ou très petite instance active | Aucun passage régulier sans visite |
| Webcron | Requête HTTP externe toutes les cinq minutes | Hébergement sans accès au planificateur système | Dépendance au réseau et au service externe |
| Cron système | Commande locale toutes les cinq minutes | Serveur, VPS ou conteneur administré | Nécessite un accès à l’environnement d’exécution |
Pour une instance de production, choisissez cron dès que l’environnement le permet. Ne réduisez pas l’intervalle au hasard pour corriger un retard. La documentation officielle demande un passage toutes les cinq minutes. Une tâche peut aussi attendre sa propre échéance ou une ressource externe, même si cron.php est appelé plus souvent.
Comment configurer le cron Nextcloud sur un serveur Linux ?
Commencez dans l’interface d’administration et sélectionnez Cron dans la section des tâches d’arrière-plan. Identifiez ensuite le compte qui exécute PHP pour le serveur web. Sur Debian et Ubuntu avec Apache ou PHP-FPM, il s’agit souvent de www-data, mais ce nom n’est pas universel.
Ouvrez la crontab de ce compte :
sudo crontab -u www-data -e
Ajoutez une ligne en adaptant le chemin de PHP et celui de Nextcloud :
*/5 * * * * /usr/bin/php -f /var/www/nextcloud/cron.php
L’utilisateur doit être celui du processus HTTP, comme l’indique le manuel Nextcloud. Évitez d’exécuter le fichier avec root. Une commande lancée sous un autre compte peut rencontrer des permissions différentes ou créer des fichiers avec un propriétaire incohérent.
Avant d’attendre cinq minutes, lancez exactement la même commande sous le compte prévu :
sudo -u www-data /usr/bin/php -f /var/www/nextcloud/cron.php
echo $?
Un code de sortie nul indique que le processus s’est terminé sans erreur système visible. Revenez ensuite dans les paramètres d’administration et vérifiez que l’heure du dernier passage avance. Contrôlez enfin une fonction réelle, par exemple l’arrivée d’un flux News ou l’exécution d’un traitement planifié.
Utilisez des chemins absolus
L’environnement d’une crontab est plus limité que celui d’un terminal interactif. Un chemin absolu vers PHP et cron.php évite qu’une variable PATH différente sélectionne un mauvais binaire ou ne trouve aucune commande.
Comment exécuter cron avec l’image Docker officielle ?
Dans un déploiement Docker, une crontab créée sur l’hôte ne doit pas appeler arbitrairement un fichier interne au conteneur. Le dépôt officiel de l’image Nextcloud fournit un script /cron.sh et recommande un conteneur séparé qui partage les volumes de l’application.
Voici la structure minimale à adapter au fichier Compose existant :
services:
app:
image: nextcloud
volumes:
- nextcloud:/var/www/html
cron:
image: nextcloud
restart: always
volumes:
- nextcloud:/var/www/html
entrypoint: /cron.sh
depends_on:
- app
volumes:
nextcloud:
Le conteneur cron utilise la même image et le même volume applicatif que app. Le script officiel exécute le mécanisme attendu à l’intérieur de cet environnement. Si l’installation utilise des volumes supplémentaires pour les données, la configuration ou des applications personnalisées, reproduisez les montages nécessaires au lieu de copier cet exemple sans comparaison.
Démarrez le service, puis vérifiez son état et ses journaux :
docker compose up -d cron
docker compose ps cron
docker compose logs cron
La documentation de l’image signale aussi un blocage possible par SELinux ou AppArmor sur certaines distributions. Si le conteneur fonctionne mais que cron.php n’avance pas, examinez les politiques de sécurité du système avant de modifier les permissions des volumes.
Comment régler la fenêtre de maintenance ?
Le paramètre maintenance_window_start réserve une période UTC de quatre heures aux travaux non urgents lorsque l’instance utilise cron. Il accepte une heure entière de 0 à 23. Une valeur 1 indique donc une fenêtre qui commence à 01:00 UTC, pas nécessairement à 01:00 en France selon la saison.
Dans config/config.php, le réglage prend cette forme :
'maintenance_window_start' => 1,
Cette fenêtre ne suspend pas Nextcloud et ne bloque pas les utilisateurs. Elle retarde uniquement les travaux que leur développeur a classés comme non sensibles au temps. Le tutoriel sur le mode maintenance Nextcloud explique le mécanisme distinct qui rend volontairement l’instance indisponible pendant une intervention.
Choisissez la valeur à partir de l’heure UTC, de l’activité réelle et des autres opérations lourdes. Évitez de placer sauvegardes, indexations, analyses antivirus et traitements différés dans le même créneau sans mesure de charge. Après un changement, observez plusieurs jours avant de conclure que la fenêtre réduit les ralentissements.
Le réglage n’a d’effet que si cron est utilisé. AJAX et Webcron ne donnent pas accès à cette planification des tâches non urgentes selon le manuel officiel. Vérifiez donc d’abord le mode actif et la régularité des passages.
Pourquoi le cron Nextcloud ne s’exécute-t-il plus ?
Commencez par la date affichée dans les paramètres d’administration. Si elle est ancienne, exécutez manuellement la commande de la crontab sous le même utilisateur. Une erreur immédiate permet souvent d’identifier un chemin faux, un binaire PHP absent, une extension manquante ou un problème de permission.
Vérifiez ensuite le binaire réellement employé :
sudo -u www-data /usr/bin/php -v
sudo -u www-data test -r /var/www/nextcloud/cron.php && echo "cron.php lisible"
sudo crontab -u www-data -l
Comparez la commande affichée à l’emplacement réel de l’instance. Après une migration ou une mise à niveau de PHP, la crontab peut encore pointer vers un ancien chemin. Contrôlez aussi l’horloge et le fuseau du serveur, car ils influencent votre lecture des heures, même si la planification cron reste périodique.
Si le passage général avance mais qu’une fonction reste bloquée, cherchez l’erreur de l’application. Un montage distant indisponible peut retarder la détection de fichiers. Le guide du stockage SMB avec Nextcloud montre par exemple que les changements externes dépendent aussi du serveur de fichiers, des identifiants et du mécanisme de notification.
Procédez dans cet ordre :
- confirmer le mode Cron dans l’interface ;
- vérifier la ligne de crontab et son utilisateur ;
- exécuter manuellement la commande exacte ;
- contrôler le code de sortie et les journaux Nextcloud ;
- vérifier le service PHP, la base, Redis et les stockages utilisés ;
- tester le résultat fonctionnel d’une application précise ;
- surveiller les prochains passages avant de modifier la fréquence.
Évitez de recréer la crontab plusieurs fois ou de lancer cron.php en boucle. Une erreur reproductible donne une meilleure piste qu’une hausse de fréquence. Conservez la commande, l’heure, le code de sortie et le premier message d’erreur pour comparer avant et après correction.
Conclusion
Le cron Nextcloud doit exécuter cron.php toutes les cinq minutes sous le compte du serveur web. AJAX reste dépendant des visites et Webcron d’un appel externe, tandis que cron fournit un déclenchement régulier pour les applications et les travaux différés. Sur Docker, utilisez le service dédié de l’image officielle avec les mêmes volumes. Ajoutez ensuite une fenêtre UTC pour les tâches non urgentes et surveillez le résultat réel, pas seulement la date du dernier passage.