Déballer la mise à jour ... Impossible de créer le répertoire. Wordpress
Quand j'installe les plugins nextgen-gallery. Ce message d'erreur apparaît
Downloading update from https://downloads.wordpress.org/plugin/nextgen-gallery.Zip…
Unpacking the update…
Could not create directory.
Comment puis-je résoudre ce problème?
Ceci est un problème d'autorisations. Assurez-vous que le répertoire est accessible en écriture par Apache. Les plugins sont décompressés dans le répertoire wp-content/plugins, je commencerais donc par écrire dans le répertoire en tant qu'Apache:
Sudo -u Apache touch /path/to/wp-content/plugins/test.txt
Définissez les autorisations en conséquence pour corriger le problème. Vous pouvez en savoir plus sur les autorisations ici: http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions
Vous pouvez en savoir plus sur le schéma de permissions de fichier correct pour Wordpress ici: http://codex.wordpress.org/Changing_File_Permissions#Permission_Scheme_for_WordPress
La réponse de @skrilled et @ knutole était excellente, mais j'ai constaté qu'en essayant de résoudre le problème dans le dossier des plugins, tout allait bien et que la réponse ne fonctionnait pas pour moi.
Si quelqu'un d'autre a ce problème, essayez également de consulter le dossier des mises à niveau. Ce dossier (d'après ce que je peux voir) est utilisé comme un dossier pour stocker des fichiers temporaires pour l'exécution de mises à niveau WP ou de plug-ins.
Si vous recevez simplement le message «Impossible de créer le répertoire» et qu’aucun chemin n’est spécifié, il est possible que le dossier des mises à niveau soit en fait traité.
pour les personnes nginx
si vous avez php-fpm installé, vous devez lui dire que son utilisateur et son groupe sont nginx. /etc/php-fpm.d/www.conf. trouve l'utilisateur attribué par défaut à Apache et remplacez-le par nginx. faites-le aussi pour le groupe. puis lancez cette commande:
Service Sudo redémarrage php-fpm
également à l'intérieur de votre répertoire wordpress, exécutez ces commandes
Sudo chown nginx: nginx * -R
Sudo usermod -a -G nginx nom d'utilisateur
changez le nom d'utilisateur en votre nom d'utilisateur actuel .
vous devez cependant appliquer les autorisations appropriées . exécuter ces commandes dans votre répertoire wordpress
Sudo trouver. -type f -exec chmod 664 {} +
Sudo trouver. -type d -exec chmod 775 {} +Si vous utilisez vsftpd comme serveur FTP et avez activé les connexions passives, vous devez ajouter pasv_promiscuous=YES à /etc/vsftpd/vsftpd.conf.
Je cours Nginx avec Wordpress. J'ai supprimé le dossier de mise à niveau dans wp-content, puis j'ai à nouveau lancé la mise à niveau à partir de l'interface graphique wordpress. J'ai noté que l'utilisateur Linux du dossier de mise à niveau créé était www-data. J'ai ensuite fait une opération {Sudo chmod -R www-data: www-data.} A exécuté la mise à niveau à nouveau à partir de l'interface graphique et tout a fonctionné.
Il faudra probablement modifier les autorisations sur la plupart des dossiers afin qu'ils ne puissent pas être modifiés par www-data, mais je le saurai demain.
(Re) définir les autorisations via ftp ne m'a pas non plus changé. Il n'y a pas de SSH disponible, j'ai donc dû ouvrir une session dans le panneau de configuration (directadmin dans mon cas), dans le gestionnaire de fichiers où je pouvais "Réinitialiser le propriétaire" sur "Propriété du fichier réinitialisé" dans le répertoire/wp-contents.
J'avais un problème similaire. Tout a commencé avec la tentative de mise à jour d'un plug-in sur une installation WP migrée. Je ne l'ai pas eu, toutes mes autorisations étaient EXACTEMENT identiques à celles de l'ancien serveur. Dans ma situation, j'ai commencé à voir que peu fonctionnait correctement. Je ne pouvais pas installer/supprimer de plug-ins ou de thèmes, et le téléchargement d'un média entraînerait une erreur. Ensuite, j'ai trouvé le correctif via des recherches.
Si vous rencontrez toujours ce problème et que vous modifiez les autorisations DID, ne résolvez PAS le problème, essayez ceci:
Accédez à votre panneau de configuration hosting et recherchez vos paramètres d'hébergement, où que vous puissiez modifier vos paramètres de script. Dans Plesk (comme dans mon exemple), ce serait sous Sites Web et domaines. Cliquez sur votre nom de domaine en bas. Sur l'écran suivant, où il est indiqué "Prise en charge de PHP (exécuté sous ..." changez le menu déroulant de "module Apache" sur "Application FastCGI" . à présent!
Un problème d'autorisation, assurez-vous qu'Apache (www-data) dispose d'autorisations en écriture.
Tout ce qui précède est excellent, mais je pense que vous avez manqué le problème le plus simple. Votre site Web utilise plus d’espace que prévu, et il est donc en panne. Wordpress crée plus de fichiers en cours d'utilisation. Si vous êtes sur le point de passer à autre chose, une simple question du jour au lendemain où vous n'avez rien fait est possible. Allez au lit, tout va bien. Dans la matinée, le site Web est en panne.
Je possède mes sites Web et je vais donc dans la partie revendeur de Hostmonster ou Hostgator (j'ai des sites sur les deux plates-formes d'hébergement) et je réaffecte plus d'espace. Le problème disparaît généralement. Essayez-le d'abord ou examinez-le avant de vous occuper des autorisations. Si vous avez modifié une autorisation et que le problème est survenu, il peut s'agir d'autorisations, sinon, vérifiez d'abord.
Très probablement, si vous l'avez configuré correctement, le serveur http associé à votre site wordpress appartient au groupe www-data. Voilà comment on devrait le configurer correctement.
Essayez members www-data et ps aux | grep www-data pour en être sûr. Dans la dernière commande, vous devriez voir sur les dernières colonnes soit nginx ou Apache.
Dans ce cas, il vous suffit de définir ce groupe dans le répertoire
Sudo chgrp -R www-data <your_wordpress_root_dir>/
puis ajoutez des autorisations de groupe complètes à ce répertoire
Sudo chmod -R g+rwx <your_wordpress_root_dir>/
Maintenant cela fonctionne parfaitement :)