Sziasztok! Most tettem föl egy friss magyar wordpress-t (3.8.1) egy ubuntu 12.04 LTS szerverre. Az a gondom, hogy az admin felületből nem tudok telepíteni bővítményeket. Ha telepíteni próbálom, akkor az FTP kapcsolódási paramétereket hozza be. Ezen a szerveren nincs FTP, és nem is szeretném hogy legyen. Viszont adtam írási jogot a www-data csoportnak a wp-content könyvtárra, azon belül a plugins könyvtárra is. (Meg igazából szinte minden más könyvárra is.) Ennek ellenére nem akar telepíteni direktbe csak ftp-n keresztül. Az apache error logban nincs róla semmi. A dokumentációt néztem ott azt írták hogy csak a plugins mappára kellene írási jog, de ezek szerint mégse. 777 joggal se ment! Mit csináljak?
Ha az egész public_html könyvtár tulajdonosát átállítom www-data -ra akkor működik. De továbbra is áll a kérdés. Szeretném tudni hogy pontosan milyen könyvtárra milyen jogosultságok szükségesek. Nem tetszik, hogy a user a saját könyvtárában levő állományokat nem tudja írni.
Normális esetben a telepítés ftp-n keresztül történik. Lehúzza, kicsomagolja, telepíti. Normál linuxos beállítások kellenek jól belőtt szerver esetén (ha valami elvont, extrém beállítások vannak a szerveren, nem kell csodálkozni, hogy nem úgy akar működni, ahogy elvárnánk): könyvtár 755, fájlok 644 (védettebb fájloknál lehet 640 vagy 600).
Próbáld ki ezt - a wp-config.php-ban a helye, de nem 100%, hogy működik:
define('FS_METHOD','direct');
a legvégére, ez után a sor után:
require_once(ABSPATH . 'wp-settings.php');
Lehúzza? Úgy érted feltölti? Ha jól értelmezem akkor az ftp arra kell, hogy azon keresztül tudjon írni a wordpress a wp-content könyvtárba. Azaz nem letöltésre hanem feltöltésre használja.
Ezekkel a jogokkal mindig baj szokott lenni. Az apache általában egy adott user, a sok virtualhost meg sok külön user alatt van. Ha a virtualhost-ok egy user alá kerülnek, akkor a user-ek írják egymás adatait ami nem jó. Ha külön user-ek alatt vannak akkor meg az apache process nem tudja írni normálisan a könyvtárakat. Végső megoldásként apache SuExecUserGroup, de akkor meg elmondunk a mod_php-ről, a teljesítmény romlik és újabb security problémák jönnek be. Nem tudom talán még azt lehetne hogy minden usernek külön apache és elé egy ngnx. Vagy mindenkinek saját virtuális gép. De az meg “kicsit” teljesítmény igényes. Értem hogy az ftp-s elérés áthidalja a probléma egy részét ha a wordpress támogatja az ezen keresztül való file írást. De a probléma gyökerét nem sikerült még megoldani. Már 5 éve is ez volt a problémám és azóta sincs rá normális megoldás. 
Ami a javaslatodat illeti:
<code>chown -R myuser:www-data public_html<br />
chmod 2770 public_html<br />
cd public_html<br />
chmod 2770 wp-admin wp-content wp-includes wp-content/plugins<br />
</code>
```<br />
<br />
Ezek után beírtam a végére amit mondtál:<br />
<br />
<code>define('FS_METHOD','direct');</code><br />
<br />
Ezek után a telepítés SIKERÜLT! Ezek szerint az FS_METHOD kellett hozzá. A jogokkal eddig se volt baj (777 joggal se akart működni). Így hogy a set guid bit be van állítva, az állományok www-data:www-data jogokkal jönnek létre. Ez nem tökéletes, de nem is olyan rossz - a user-emet a www-data csoportba tettem és így elfogadható kompromisszum alakult ki.<br />
<br />
Köszönöm!Érdekes meglátás. Nekem az elmúlt majd 12 évben nem volt problémám a jogosultságokkal (sem desktopon, sem weben). Ott valami nem kóser. Linux alatt az userek nem is látják egymás dolgait, nemhogy írni tudnák. Kivéve, ha szándékosan jogot adsz neki. (Bár az ubuntu egy külön állatfaj 
).
Akkor kifejtem bővebben. Tegyük föl hogy van user1 és user2 akiknek van weblapjuk site1 és site2. Tegyük föl hogy apache virtualhost-ot használnak. Az apache web szerver valamilyen www user és www group nevében fut.
Alap probléma: ~user1/public_html és ~user2/public_html könyvtárat el kell hogy érje a www:www user nevében futó apache process. Íme a lehetőségek:
#1. ~user1/public_html tulajdonosa user1:www, és ~user2/public_html tulajdonosa user2:www, valamint a public_html könyvtárakra adunk írási jogot www user-nek. Ezzel több baj is van. Az egyik probléma, hogy azok az állományok amiket apache/PHP hoz létre (pl. valaki weblapot feltölt egy képet) azok www:www tulajdonában lesznek. Ezért az a helyzet áll elő, hogy a ~user1 home-jában megjelennek olyan állományok amiknek nem user1 a tulajdonosa. Alapvető elvárás, hogy “ami az én könyvtáramban van azt tudjam módosítani”. Ez csak úgy elképzelhető, ha user1 login group-ja www. (Ellenkező esetben user1 home-jában lesznek olyan állományok amiket nem tud se módosítani se törölni…) Ha viszont user1 és user2 is benne van a www csoportban, akkor user1 ugyan így írni tudja user2 neve alatt levő, www csoportú állományokat!
Szóval ennél a megoldásnál választani kell, hogy a felhasználók vagy nem érik el teljeskörűen a saját home-jukat, vagy van egy nagy security hole: egymás honlapjának a tartalmába bele tudnak írni.
#2. Az is egy lehetőség, hogy a ~user1/public_html és ~user1/public_html tulajdonosa is www:www lesz. Ekkor a felhasználók nem tudnak beleírni egymás honlapjába. De sajnos a sajátjukba se! (Vagyis közvetlenül nem, apache-on keresztül persze igen.)
#3. Az is lehetséges, hogy apache config-ban SuExecUserGroup használatával rávesszük apache-ot arra, hogy minden user home-jában a PHP az adott user jogaival fusson. Ezzel is van gond: a jogosultságok ugyan jók lesznek, azonban ilyenkor a mod_php nem használható, minden kód CGI-ként fut, lelassul a szerver, főleg akkor ha sok user-nek egyszerű honlapja van.
#4. A legtisztább megoldás: minden user kap egy virtuális gépet. Ezen a gépen belől az adott user saját felhasználója megegyezik az apache felhasználóval. Tetszőlegesen tud írni olvasni mindent, és tökéletesen el van különítve a több user-től. De ez még erőforrásigényesebb.
Mindegyik megoldásnak van hátránya. Ha egy olyan szolgáltató szemszögéből nézed a dolgot, aki megpróbál webtárhely szolgáltatást nyújtani, akkor #1 és #2 nyilván nem jó, mert így nem lehet garantálni az ilyen szolgáltatások esetén rendkívül fontos feltételeket egyidőben (a saját állományait teljes körűen elérje, és ne tudja elérni más emberek állományait). #1 és #2 esetén lehet áthidaló megoldás az ftp vagy sftp szerver, aminél a user úgy loginol be, hogy az ftp kiszolgáló a saját home-jába chroot-ol. Ha valaki kizárólag webtárhely szolgáltatást nyújt, akkor ez jó megoldás lehet. Nagyon sok szolgáltató ezt a megoldást alkalmazza. De ha már nem csak webtárhely szolgáltatást nyújtasz, hanem mondjuk meg akarod engedni bizonyos user-eknek hogy bejelentkezzenek ssh-val és cron job-okat futtassanak, akkor megette a fene az egészet! A #3/#4 -nek nyilvánvaló hátránya hogy minden user számára egy teljes virtuális gépet kell telepíteni beállítani és üzemeltetni, és sok erőforrást fölhasználni.
Olyan igazán jó megoldást (minden jog a helyén van, a user be tud login-olni és parancsokat futtatni, és nem kell CGI-zni meg virtuális gépet futtatni) nem tudok. De ha valaki tud akkor szóljon.