Nu pot instala plugin-uri noi din cauza erorii "Could not create directory"

Question

Nu pot instala plugin-uri noi din cauza erorii "Could not create directory"

24 sept. 2010, 22:19:12

Vizualizări: 38.5K

Voturi: 7

Un membru al facultății întâmpină dificultăți cu o instalare WordPress pentru instruire. Remedierea problemelor individuale de permisiuni a fost hit-or-miss și a devenit o problemă recurentă, așa că voi întreba aici. Ce pot face pentru ca WP să funcționeze corect? Tipurile de erori pe care le întâlnesc:

Instalare Plugin: Lightbox 2 2.9.2 Descărcare pachet de instalare de la http://downloads.wordpress.org/plugin/lightbox-2.2.9.2.zip… Despachetare pachet… Nu s-a putut crea directorul. /home/CIM140/public_html/wordpress/wp-content/upgrade/lightbox-2.tmp

Când mă autentific ca www-data (utilizatorul sub care rulează Apache în Ubuntu), pot crea acel director fără probleme. Instanța mea de test WP instalează acest plugin fără probleme, așa că nu înțeleg de ce eșuează pentru ei.

jldugger

173

pluginuri permisiuni actualizări

Toate răspunsurile la întrebare

Comentarii

Am făcut deja asta =(

jldugger

24 sept. 2010 22:39:50

exemplu: drwxrwsr-x 6 www-data www-data 4096 2010-09-22 23:15 wp-content

jldugger

24 sept. 2010 22:40:53

Încearcă să le schimbi în drwxr-xr-x 7 www-data www-data 4096 Sep 24 09:38 wp-content

Chris_O

24 sept. 2010 23:01:13

De asemenea, nu am folosit niciodată atributul SGID pe un director, adică: chmod g+s. Nu cred că este necesar. Cineva să mă corecteze dacă greșesc.

Chris_O

24 sept. 2010 23:13:02

Ah, după ce am luat legătura cu facultatea, se pare că implicit folosește SSH, în timp ce instanța mea de testare folosește IO direct. Deci problema este că utilizatorul său nu are drepturi de a crea directorul.

jldugger

25 sept. 2010 01:17:48

Arată celelalte 1 comentarii

Pentru a înțelege de ce întâmpinați aceste probleme, trebuie să înțelegeți conceptele de bază ale drepturilor de proprietate.

În esență, știți că Apache rulează sub utilizatorul www-data. Acesta este motivul pentru care setarea tuturor fișierelor să fie deținute de acest utilizator funcționează, deoarece WordPress verifică dacă poate crea fișiere ca utilizatorul care deține fișierele sale. Deci, ceea ce faceți este să faceți totul deținut de utilizatorul care deține fișierele.

Dacă aveți control total asupra mașinii, acest lucru este în regulă. Pe de altă parte, dacă este un server de hosting partajat, atunci ați creat o breșă de securitate.

În mod normal, serverele web rulează sub un anumit utilizator (cum ar fi www-data), care apoi rulează codul altor utilizatori (cum ar fi "otto", contul meu de utilizator). În această situație, serverul web nu ar avea capacitatea de a crea fișiere ca "otto" și, astfel, nu ar putea crea corect fișiere ca contul meu. Prin urmare, această verificare a WordPress-ului privind crearea de fișiere cu proprietari corecți și, astfel, capacitatea de a instala plugin-uri sau de a actualiza fișiere ar eșua, corect, deoarece a avea fișierele mele deținute de utilizatorul partajat al serverului web ar reprezenta un risc de securitate.

În astfel de cazuri, WordPress ar trebui să mă solicite corect credențiale FTP sau ceva similar. Acestea ar fi o modalitate de a ocoli problema contului de utilizator prin autentificarea ca utilizatorul care ar trebui să scrie fișierele și apoi scrierea acestora ca acel utilizator.

Acum, încercați să rezolvați această problemă schimbând toate fișierele WordPress să fie deținute de același cont ca cel sub care serverul web scrie fișierele. Abordarea mai normală pentru aceasta este să schimbați modul în care serverul web scrie fișiere, pentru a permite procesului PHP să fie "deținut" de contul de utilizator sub care rulează fișierele.

Răspunsul general la aceasta este "suPHP". Această versiune de PHP setează utilizatorul sub care rulează procesul PHP la același utilizator ca proprietarul fișierelor PHP pe care le rulează. Acest lucru este mai sigur pe configurațiile de hosting partajat, deoarece asigură că un proces PHP rulat de serverul web partajat rulează ca proprietarul fișierelor PHP și, astfel, nu poate citi conturile altor utilizatori și altele asemenea.

Pe Ubuntu, cred că acesta este modul general de a face acest lucru:

Instalați suPHP:

$ sudo apt-get install libapache2-mod-suphp

Dezactivați mod_php vechi

$ sudo a2dismod php5

Reporniți Apache

$ sudo /etc/init.d/apache2 restart

Și gata. Acum, aveți fișierele PHP ale WordPress-ului deținute de proprietarul lor normal. Fără trucuri speciale, fără a schimba permisiunile sau proprietatea sau alte lucruri de genul acesta. Deoarece procesul PHP va rula ca proprietarul acelor fișiere, atunci va putea scrie în ele ca acel proprietar. Directoarele ar trebui să aibă permisiunile 755, iar fișierele 644 (notă, suPHP nu apreciază când fișierele sunt scrise de grup, deci 755/644 este setul corect de permisiuni).

Otto

32.8K

17 apr. 2016 12:31:35

Pentru mine (pe Ubuntu) a trebuit să adaug umask 002 în /etc/apache2/envvars pentru a permite WordPress să încarce plugin-uri/imagini cu permisiunile 775 în loc de 755 (adică să permită oricui, în afară de Apache și root, să modifice fișierele încărcate)

willbradley

99

27 sept. 2013 01:32:39

Trebuie să acordați permisiuni de scriere pentru directoarele relevante. În mod ideal, ar trebui să faceți acest lucru doar pentru fișierul sau folderul relevant și apoi să restabiliți permisiunile înapoi, pentru a nu lăsa site-ul vulnerabil.

Puteți remedia această problemă folosind următoarele comenzi din linia de comandă (presupunând că vă aflați în folderul rădăcină al Wordpress):

# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade

Cea mai sigură soluție este să adăugați Apache în același grup ca și proprietarul instalației Wordpress și să schimbați toate permisiunile de grup în mod de scriere.

Varun

99

17 apr. 2016 10:03:28

Comentarii

Dacă există o soluție mai detaliată, adaug-o aici, în loc să o legi. 2. nu, serverul web nu ar trebui să aibă în niciun fel posibilitatea de a scrie direct în directoarele de cod, decât dacă îți place să fii hack-uit.

Mark Kaplun

17 apr. 2016 10:14:30

@MarkKaplun dar atunci actualizările extensiilor nu funcționează, ceea ce majoritatea utilizatorilor WP consideră mod "normal" de a gestiona un site. O afirmație puțin prea dură. Faptul că serverul poate scrie peste wp-content este relativ mai rău pentru securitate, dar de la sine nu este o problemă foarte mare.

Rarst

18 apr. 2016 09:36:12

@MarkKaplun: Chiar și răspunsul acceptat spune practic același lucru - singura diferență este că acesta este specific pentru Apache, în timp ce al meu este generic.

Varun

23 iun. 2016 07:31:14

Dacă răspunsul tău este același, care este rostul de a-l avea? 2.Cine a spus că răspunsul acceptat este grozav?

Mark Kaplun

23 iun. 2016 08:54:52

@Rarst, este de asemenea mai puțin convenabil să încuie ușa de la intrarea casei și să închizi ferestrele. Dacă oamenii preferă să caute fișiere hackuite pe tot serverul lor în loc să se uite doar în directorul uploads, ei pot face ce sugerează răspunsul. Actualizările de pluginuri/teme Wordpress se fac cel mai bine prin intermediul unui server ftp dacă nu dorești să folosești o aplicație client sftp.

Mark Kaplun

23 iun. 2016 09:03:00

Am avut câteva site-uri unde corectarea permisiunilor pentru directoare și fișiere nu a fost suficientă pentru a rezolva problema. Am descoperit apoi că unul sau mai multe directoare aveau setat flag-ul "immutable". Această problemă poate fi rezolvată ușor rulând chattr -R /var/www/sub.domain.tld ca root.

Phil Gardner

1

28 nov. 2019 17:08:49

Soluția foarte ușoară este: schimbarea permisiunilor folderului opt prin rularea comenzii sudo chmod -R 777 /opt.

Kumar Saurabh

1

7 ian. 2021 07:32:29

Comentarii

Te rugăm să [editezi] răspunsul tău și să adaugi o explicație: de ce ar putea asta rezolva problema? De ce crezi că este o soluție bună să permiți tuturor să citească, să scrie și să execute fișiere în aceste directoare?

fuxia

8 ian. 2021 02:04:01

Chris_O 20.6K · Accepted Answer · 2010-09-24T22:35:44Z

@pwnguin,

Am avut aceleași probleme cu mod_php pe WordPress și în cele din urmă am reușit să le rezolv.

# chown www-data:www-data  /home/CIM140/public_html/wordpress/ -R

Atâta timp cât TU administrezi serverul, această soluție nu va cauza probleme de securitate.

EDIT:

Poate fi necesar să schimbi umask-ul în 022, astfel încât noile directoare create de WordPress să aibă permisiunile 755, iar fișierele să aibă 644.

O altă opțiune este să suprascrii permisiunile implicite în wp-config.php:

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

De asemenea, poți forța metoda de sistem de fișiere pentru actualizări.

(Preferința principală) "Direct" forțează utilizarea cererilor Direct File I/O din PHP, ceea ce poate crea probleme de securitate pe serverele prost configurate. Această metodă este aleasă automat atunci când este potrivită.
(A doua preferință) "ssh" forțează utilizarea extensiei SSH PHP.
(A treia preferință) "ftpext" forțează utilizarea extensiei FTP PHP pentru accesul FTP.
(A patra preferință) "ftpsockets" utilizează clasa PHP Sockets pentru accesul FTP.

Acestea pot fi definite în wp-config.php cu: define('FS_METHOD', 'ftpext');

Poți obține toate constantele definite în prezent executând comanda print_r(@get_defined_constants()); în PHP.