Sh: /dev/null: Permission denied

Bonjour,

Un des développeurs du CMS Contao a regardé mon problème et m'indique ceci :


Je pense qu'il s'agit d'une mauvaise configuration de l'hébergement. J'ai découvert que le binaire PHP est en fait là, mais l'exécution du processus échoue. Cela semble être dû au fait que l'utilisateur d'hébergement n'a pas accès à /dev/null.

J'obtiens cette erreur lorsque j'essaie d'exécuter la commande :
*******************************************************
The command “‘/usr/local/php7.4/bin/php’ ‘-q’ ‘/home/restauraluu/www/web/contao-manager.phar.php’ ‘test’” failed.
Exit Code: 1(General error)
Working directory: /home/restauraluu/www
Output:
================
Error Output:
================
sh: /dev/null: Permission denied
at phar:///home/restauraluu/www/web/contao-manager.phar.php/vendor/symfony/process/Process.php:269
*******************************************************


voici ce que le processus Symfony exécute :
*******************************************************
{ (exec ‘/usr/local/php7.4/bin/php’ ‘-q’ ‘/home/restauraluu/www/web/contao-manager.phar.php’ ‘test’) <&3 3<&- 3>/dev/null & } 3<&0;pid=$!; echo $pid >&3; wait $pid; code=$?; echo $code >&3; exit $code
*******************************************************

Je pense que vous devriez contacter OVH à propos de ce problème de /dev/null

sh: /dev/null: Permission denied

pour documenter, ceci exécuté depuis php-cgi sur un hébergement OVH:

p0wny@shell:…/x/www# ls -l /dev/null
crw-r--r-- 1 root ovhnogroup 1, 3 Jan 12 02:39 /dev/null

p0wny@shell:…/x/www# ls -ln /dev/null
crw-r--r-- 1 0 99 1, 3 Jan 12 02:39 /dev/null

La même commande sur un debian renvoie effectivement
`crw-rw-rw- 1 root root 1, 3`

Bonjour et merci pour votre réponse.
Comme je ne suis pas un expert pour les commandes en ligne ^^... pouriez-vous m'espliquer SVP ?
Cela signifie-t-il que vous avez bien accès au dossier /dev/null de votre côté ?

Comme je ne suis pas un expert pour les commandes en ligne ^^.

C'est un hébergement Perso, donc pas d'accès ssh.

Si vous êtes curieux, voyez le prompt 'p0wny' ...

oK.
J'ai bien un accès SSH sur mon hébergement cité en exemple pour info.
Je suis sur un PRO2014

J'ai bien un accès SSH

Ca pourrait donner un résultat différent, les deux environnements d'exécution ne sont pas les mêmes entre ssh/cron et serveur web.

p0wny@shell:…/x/www# ls -l /dev/null
crw-r--r-- 1 root ovhnogroup 1, 3 Jan 12 02:39 /dev/null

p0wny@shell:…/x/www# ls -ln /dev/null
crw-r--r-- 1 0 99 1, 3 Jan 12 02:39 /dev/null

Et si tu refais la même chose uniquement sur /dev ça donne quoi de ton côté STP ?

la même chose uniquement sur /dev

# ls -l /dev
total 0
crw------- 1 root ovhnogroup 5, 1 Jan 12 02:39 console
lrwxrwxrwx 1 root ovhnogroup 13 Jan 12 02:39 fd -> /proc/self/fd
crw-r--r-- 1 root ovhnogroup 1, 7 Jan 12 02:39 full
srw-rw-rw- 0 root root 0 Jan 11 05:07 log
crw-r--r-- 1 root ovhnogroup 1, 3 Jan 12 02:39 null
lrwxrwxrwx 1 root ovhnogroup 8 Jan 12 02:39 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Jan 12 02:39 pts
crw-r--r-- 1 root ovhnogroup 1, 8 Jan 12 02:39 random
lrwxrwxrwx 1 root ovhnogroup 15 Jan 12 02:39 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root ovhnogroup 15 Jan 12 02:39 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root ovhnogroup 15 Jan 12 02:39 stdout -> /proc/self/fd/1
crw-r--r-- 1 root ovhnogroup 5, 0 Jan 12 02:39 tty
crw-r--r-- 1 root ovhnogroup 1, 9 Jan 12 02:39 urandom
crw-r--r-- 1 root ovhnogroup 1, 5 Jan 12 02:39 zero


# ls -l /proc/self/fd
total 0
lrwx------ 1 x users 64 Jan 12 15:24 0 -> socket:[341223627]
l-wx------ 1 x users 64 Jan 12 15:24 1 -> pipe:[341221697]
l-wx------ 1 x users 64 Jan 12 15:24 2 -> pipe:[341221697]
lr-x------ 1 x users 64 Jan 12 15:24 3 -> /home/x/www/shellX.php
lr-x------ 1 x users 64 Jan 12 15:24 4 -> /proc/24078/fd

(x c'est mon login)

Merci :)
Est-ce que cela signifie que les dossiers "/dev" et "/dev/null" sont accessibles sans restriction chez toi ?

Tu télécharges p0wny shell et tu testes toi-même.

Courage.

Bonjour,
je rencontre le même problème sur un projet symfony, avec une librairie qui me permet de générer des pdf. Tout fonctionnait correctement depuis des mois et du jour au lendemain j'ai la même erreur sh: /dev/null: Permission denied.

J'ai contacté le service support mais toujours pas de réponse.
Avez-vous trouvé une solution depuis ?
Cordialement.

Bonjour et merci pour votre retour.

Pour ma part, j'ai toujours un ticket en cours chez OVH... les délais de réponses ne sont pas très rapides.
Pour le moment ils ne m'ont pas proposés de solutions.

Visiblement vous avez le même soucis que moi car mon CMS Contao est également basé sur Symfony.
Tout fonctionnait correctement il y a 2 ou 3 mois et depuis erreur !

N'hésitez pas à relancer le support et à les appeler en insistant sur le faite que nous sommes plusieurs à rencontrer le problème.
A plusieurs nous auront plus de chance d'avoir un retour... j'espère ^^

On se tien au jus ;)

Bonjour,

Voici une information complémentaire de la part d'un des développeurs du CMS Contao concernant notre problème :

Nous utilisons le composant Symfony Process qui renvoie cette erreur.
Cependant, la recherche de "sh:/dev/null: Permission refusée" me donne plusieurs résultats concernant le chroot, à peu près sûr qu'OVH l'utilise sur le serveur.

Je ne sais pas si cela aide…
https://superuser.com/a/1184805
https://superuser.com/questions/1310770/fixing-dev-null-permission-denied-repeatedly-in-chroot

Sachez que tout fonctionne peut-être en utilisant SSH, mais le processus PHP peut avoir son propre environnement chailroot

Un petit message rapide ce matin, pour vous indiquez que de mon côté, l'erreur s'est "volatilisée" sans aucune action de ma part et sans aucun retour du service de support d'OVH.
J'espère que vous aurez aussi cette chance ;)

Et non, j'ai toujours l'erreur de mon côté ^^
Merci pour l'info.

Bonjour,
Même problème pour nous également...

Bonjour,
Même problème pour nous également...

Je ne peux que vous conseiller de déposer un ticket auprès de OVH... en espérant que cela fasse avancer les choses...
On ne doit pas être les seuls !

Joie de courte durée, le bug est de retour de mon côté.

Cela dit, je m'occupe d'un autre site internet avec la même fonctionnalité, qui a connu le même bug sur une durée de 24h, avant de disparaitre à nouveau, sans aucune intervention de ma part.

L'erreur faisant référence à un répertoire sur le serveur mutualisé dont on a pas accès à la configuration, je pense que le problème provient du côté d'Ovh mais le fait que le bug soit revenu me fait penser que le code déclenche peut-être se bug mais rien de certains.

Aussi, le service support a répondu à mon ticket en me disant qu'il ne traitait pas ce genre de problème et de vérifier si ma fonctionnalité était compatible avec la version de php utilisé par notre serveur.

Donc retour au point de départ.

Je pense qu'il s'agit d'un problème de droits et d'autorisations au niveau de l'hébergement.
Cela semble être dû au fait que l'utilisateur d'hébergement n'a pas accès à /dev/null.

Nous utilisons le composant Symfony Process qui renvoie cette erreur.
Cependant, la recherche de "sh:/dev/null: Permission refusée" me donne plusieurs résultats concernant le chroot, à peu près sûr qu'OVH l'utilise sur le serveur.

Pour info j'ai 41 sites concernés par le problème (qui est survenus du jour au lendemain...) alors que tout fonctionnait correctement avant.

Bonjour une solution m'a été proposée par OVH pour info :

************************************************************
Commentaires de résolution :

Comme vu ensemble ce jour, nous avons effectué avec vous un changement de la valeur "app.engine" contenue dans le fichier .ovhconfig de votre hébergement.

L'installation de Contao est effective.

Nos administrateurs sont informés, et une résolution globale est prévue sur l'ensemble de nos serveurs. Nous n'avons pour l'instant pas de délai annoncé pour ce déploiement.

Comme vu ensemble ce jour, nous avons effectué avec vous un changement de la valeur "app.engine" contenue dans le fichier .ovhconfig de votre hébergement.

Bonjour,

Pouvez-vous faire profiter la communauté en indiquant ce que vous avez changé et par quoi vous l'avez changé ?

Oui dans le fichier .ovhconfig
Nous avons modifié la ligne "app.engine=phpcgi" par "app.engine=php"
Nous avons ensuite fait une actualisation de la page du module d'installation qui posait problème.
Une fois le message d'erreur disparu, nous avons remis "app.engine=phpcgi" dans le fichier .ovhconfig.

C'est une solution temporaire pour palier au problème.

Bonjour,

Pourquoi ne pas rester en PHP ?
Normalement c'est le moteur qui est le plus performant.

Cordialement, janus57

Pourquoi ne pas rester en PHP ?
Normalement c'est le moteur qui est le plus performant.

Car le CMS Contao est plus performant sur du phpcgi