Fix “PHP Memory Limit Below Recommended Value” in ownCloud 10

The result you want is not merely “the warning disappeared.” A correct fix means the PHP process that actually serves ownCloud 10 reports a memory limit of at least 512 MB, the ownCloud admin warning clears, scheduled or CLI jobs use an appropriate limit too, and the host still has enough physical memory to run PHP, the web server, the database, and background jobs without heavy swapping.

For ownCloud Classic 10.16, the official Docker environment uses OWNCLOUD_MEMORY_LIMIT=512M as its recommended default. ownCloud's documentation also distinguishes the PHP configuration used by the web server from the one used by php-cli. That distinction is the main reason administrators sometimes change memory_limit, restart a service, and still see the same warning.

This guide starts with the least disruptive checks, then shows Apache, PHP-FPM, CLI, and Docker paths. It also explains when increasing the limit further is justified and when the real problem is insufficient host RAM rather than the PHP setting itself.

What success looks like

1. Confirm the warning and the value ownCloud sees

Open the ownCloud administration settings and note the memory-limit warning. Before changing anything, record the ownCloud version, PHP version, web server type, and current memory limit. This gives you a baseline and helps prevent changing the wrong PHP installation on systems with multiple PHP versions.

ownCloud's current 10.16 documentation says server requirements depend heavily on user count, file count, and activity. Its Docker configuration sets OWNCLOUD_MEMORY_LIMIT=512M and recommends keeping that default. This makes 512 MB a sensible baseline for resolving the warning, not a guarantee that every workload will fit within 512 MB.

Official references: ownCloud deployment recommendations and ownCloud Docker environment variables.

2. Do not trust the CLI value to represent the web server

Run these commands to see what the command-line PHP process uses:

php --ini
php -r 'echo ini_get("memory_limit"), PHP_EOL;'

This is useful for occ and cron jobs, but it is not proof of what the web request uses. ownCloud explicitly documents separate configuration paths such as:

/etc/php/<version>/apache2/php.ini
/etc/php/<version>/fpm/php.ini
/etc/php/<version>/cli/php.ini

If your CLI says 512M while the admin page still complains, that mismatch is a strong sign that the web server is loading another php.ini.

See ownCloud's PHP configuration notes, which specifically warn that PHP settings may need to be changed in more than one INI file.

3. Find the PHP configuration used by the web request

The most reliable test is to inspect PHP from the same web stack that serves ownCloud. ownCloud's documentation describes using a temporary phpinfo.php page:

<?php phpinfo(); ?>

Place it temporarily in the web root, open it in a browser, and locate:

• Loaded Configuration File
• memory_limit
• Server API

Then delete the phpinfo file immediately. ownCloud warns that leaving a public phpinfo page exposes sensitive server information.

If the browser says /etc/php/7.4/fpm/php.ini while php --ini says /etc/php/7.4/cli/php.ini, you now know exactly why editing the CLI file did not clear the warning.

4. PHP-FPM: raise the web-runtime limit to 512M

On a typical Debian or Ubuntu installation:

sudo nano /etc/php/7.4/fpm/php.ini

Find:

memory_limit = 128M

and change it to:

memory_limit = 512M

Use your installed PHP version in the path. Then restart the correct FPM service and your web server if needed:

sudo systemctl restart php7.4-fpm
sudo systemctl reload nginx

For Apache with proxy_fcgi or another FPM setup, restart PHP-FPM and reload Apache instead.

ownCloud also notes that PHP-FPM does not consume PHP settings from .htaccess. If you rely on per-directory overrides with FPM, use the supported PHP/FPM configuration mechanism for your environment, such as the appropriate php.ini, pool configuration, or .user.ini.

5. Apache with mod_php: edit the Apache PHP configuration

If Apache loads PHP directly as a module, edit the Apache-specific file:

sudo nano /etc/php/7.4/apache2/php.ini

Set:

memory_limit = 512M

Then restart Apache:

sudo systemctl restart apache2

Do not copy the version number mechanically. Check the version actually loaded by Apache. Systems upgraded across several PHP releases often retain multiple directories under /etc/php/.

The result criterion is simple: after the restart, the web-facing PHP runtime must show the new value. If it still shows 128M, another configuration layer is overriding your edit.

6. Mettez à jour la limite de l'interface de ligne de commande lorsque occ ou cron utilise trop peu de mémoire.

L'avertissement de l'interface d'administration web est géré par l'environnement d'exécution web, mais occles tâches cron utilisent l'interface de ligne de commande PHP. La documentation d'ownCloud le précise explicitement.

Modifier:

sudo nano /etc/php/7.4/cli/php.ini

Ensemble:

memory_limit = 512M

Vérifiez ensuite :

php -r 'echo ini_get("memory_limit"), PHP_EOL;'

Il n'est pas nécessaire de redémarrer un service pour PHP en ligne de commande, car chaque invocation lance un nouveau processus. Toutefois, si votre tâche cron appelle explicitement un autre binaire PHP, vérifiez ce binaire précis au lieu de supposer /usr/bin/phpqu'il est utilisé.

ownCloud recommande de l'exécuter occen tant qu'utilisateur HTTP, généralement www-datasous Debian/Ubuntu. Sa documentation officielle précise également qu'il occconvient d'utiliser la même version de PHP que le serveur web lorsque plusieurs versions sont installées.

7. Docker : utilisez OWNCLOUD_MEMORY_LIMIT au lieu de modifier les fichiers à l’intérieur du conteneur.

Pour l'image Docker officielle d'ownCloud, utilisez la variable d'environnement documentée :

environment:
  OWNCLOUD_MEMORY_LIMIT: 512M

Recréez ensuite le service :

docker compose up -d

N’effectuez pas la correction principale en modifiant le fichier de configuration php.inidans un conteneur éphémère. La recréation du conteneur peut annuler ces modifications. La documentation officielle de l’environnement Docker d’ownCloud définit OWNCLOUD_MEMORY_LIMIT=512Met recommande de conserver ce comportement par défaut.

Si l'hôte Docker lui-même a une limite de mémoire stricte, examinez également les contraintes du conteneur :

docker stats

Une limite de 512 Mo pour PHP ne confère pas automatiquement 512 Mo de mémoire libre au conteneur ; elle autorise simplement une requête PHP individuelle à consommer jusqu'à cette quantité. Le conteneur et l'hôte ont toujours besoin de suffisamment de mémoire pour exécuter simultanément tous les processus PHP et les autres services.

8. Redémarrez le service concerné et vérifiez à partir du même temps d'exécution.

Après avoir redémarré le service concerné, vérifiez à nouveau la page phpinfo temporaire ou la vue d'ensemble de l'administration ownCloud. Supprimez ensuite la page phpinfo.

Si vous avez modifié PHP-FPM, vérifiez :

sudo systemctl status php7.4-fpm
sudo systemctl status nginx

Si vous avez modifié Apache :

sudo systemctl status apache2

Actualisez la page d'administration d'ownCloud. L'avertissement devrait avoir disparu si ownCloud fonctionne désormais correctement, au moins à la limite prévue.

9. Vérifiez la RAM de l'hôte avant d'augmenter la limite PHP au-delà de 512 Mo.

Courir:

free -h
ps aux | grep php-fpm
vmstat 1

La memory_limitlimite de mémoire PHP est fixée par script. Il ne s'agit pas d'une réservation et elle est différente de la quantité de RAM nécessaire au serveur. Si vous avez 20 processus PHP et que vous autorisez chaque requête à utiliser une très grande quantité de mémoire, le pire des cas théoriques peut largement dépasser la RAM de la machine.

La documentation d'optimisation d'ownCloud contient la même mise en garde générale concernant les processus du serveur web : dimensionnez le nombre de processus de manière à ce que la consommation mémoire totale reste inférieure à la RAM disponible, faute de quoi le système commencera à utiliser la mémoire virtuelle et les performances chuteront. Consultez le guide d'optimisation d'ownCloud Classic .

Si l'avertissement 512M a disparu et que le fonctionnement normal se déroule correctement, il n'y a aucune raison d'augmenter la limite simplement pour agrandir le nombre.

10. Lorsque 512M affiche toujours le message « Taille de mémoire autorisée épuisée »

Un avertissement de recommandation effacé et un plantage dû à une saturation de la mémoire sont deux problèmes différents. Si les journaux contiennent des messages tels que :

PHP Fatal error: Allowed memory size of ... bytes exhausted

Identifiez l'opération qui la déclenche. Les analyses volumineuses, les tâches de chiffrement, les opérations sur le stockage externe, le traitement d'images ou une application tierce peuvent avoir des profils de mémoire très différents.

Consultez les journaux d'ownCloud et les journaux d'erreurs du serveur PHP/web. Une installation standard d'ownCloud enregistre ses propres journaux dans le répertoire de données configuré, généralement `/usr/local/ data/owncloud.logowncloud`. Évitez de considérer l'augmentation de la capacité à 1 Go comme une solution automatique. Vérifiez d'abord si la même opération atteint systématiquement cette limite.

Si une tâche administrative connue a légitimement besoin de plus de mémoire, une modification ciblée via l'interface de ligne de commande peut être plus sûre que d'imposer globalement une limite importante à chaque requête Web :

php -d memory_limit=1G occ <command>

N'utilisez cette fonction que si vous comprenez parfaitement le comportement de la commande et de la mémoire. Elle ne corrige pas les requêtes web exécutées via PHP-FPM ou Apache.

Pourquoi l'avertissement peut persister après la modification du fichier php.ini

Ne confondez pas la limite de mémoire avec les limites de téléchargement.

memory_limitAugmenter la mémoire allouée à PHP ne permet pas automatiquement aux utilisateurs de télécharger des fichiers plus volumineux. Les notes de configuration d'ownCloud 10.16 indiquent séparément que la mémoire allouée à PHP doit upload_max_filesizeêtre configurée à au moins 512 Mo pour le minimum documenté et expliquent que les limites de téléchargement nécessitent des paramètres spécifiques.post_max_sizepost_max_size

Si le problème se manifeste par des échecs de chargement de fichiers volumineux, vérifiez upload_max_filesizeles post_max_sizelimites de taille du corps des requêtes, les délais d'expiration et la capacité du disque temporaire du proxy/serveur web. N'utilisez pas une valeur supérieure memory_limitcomme alternative à ces mesures de contrôle.

Liste de vérification finale

• Veuillez vérifier l'avertissement et la valeur actuelle dans ownCloud.
• Identifiez si ownCloud utilise Apache mod_php ou PHP-FPM.
• Trouvez le fichier de configuration chargé du runtime web .
• Configurez le PHP web memory_limità au moins 512M.
• Mettez également à jour l'interface de ligne de commande PHP si occcron utilise une limite inférieure.
• Pour Docker, configurez OWNCLOUD_MEMORY_LIMIT=512Ml'environnement de déploiement.
• Redémarrez ou recréez le service qui héberge réellement PHP.
• Vérifiez la valeur à partir de l'environnement d'exécution Web, et pas seulement à partir de l'interface de ligne de commande.
• Vérifiez que l'avertissement d'ownCloud a disparu.
• Surveillez la RAM et la mémoire d'échange de l'hôte avant d'augmenter la limite au-delà de 512 Mo.

En résumé

Pour résoudre le problème « Limite de mémoire PHP inférieure à la valeur recommandée » dans ownCloud 10, il suffit de configurer l'environnement d'exécution PHP qui héberge ownCloud avec une limite de 512 Mo ou plus, puis de vérifier ce résultat avec ce même environnement. L'erreur la plus fréquente survient lors de la modification /etc/php/.../cli/php.inide la configuration d'ownCloud pendant son exécution via PHP-FPM ou Apache.

Arrêtez l'opération une fois l'avertissement disparu, le fonctionnement normal assuré et la mémoire disponible suffisante sur l'hôte. Si PHP consomme toujours 512 Mo lors d'une opération spécifique, passez de l'augmentation de la limite à un diagnostic de la charge de travail : examinez la commande défaillante, les applications, les journaux, la concurrence et la RAM physique. Une limite plus élevée peut être appropriée, mais uniquement si la charge de travail le justifie et que le serveur peut la supporter sans risque.