Ha a médiatár egy kép feltöltésére ezt válaszolja: „A feltöltött fájlt nem tudtam átmásolni wp-content/uploads/2026/10.” (angolul: „The uploaded file could not be moved to wp-content/uploads/2026/10.”), a fájl megérkezett a szerverre, csak az utolsó lépés hiúsult meg. A PHP előbb egy ideiglenes mappába menti a feltöltést, a WordPress pedig innen helyezné át a hónap mappájába az uploads alatt. A cPanel tárhelyeken a PHP az Ön felhasználójaként fut, tehát a hiba azt jelenti: az Ön felhasználója most nem írhat abba a mappába.

A három leggyakoribb ok: a mappa jogosultsága vagy tulajdonosa rossz (többnyire egy költöztetés vagy visszaállítás után), betelt a tárhely vagy a fájlok számának korlátja, illetve a WordPress egy rossz, például a régi tárhelyre mutató útvonalra próbál írni.

Melyik hibaüzenet melyik lépésre utal?

• „A feltöltött fájlt nem tudtam átmásolni …”: a hónap mappája létezik, de az áthelyezés nem sikerült. Erről szól ez a cikk.
• „… könyvtár létrehozása sikertelen. Írható a szülő könyvtár a szerver által?” („Unable to create directory …”): a hónap mappáját sem tudta létrehozni. Ugyanezek a lépések segítenek, csak egy szinttel feljebb, az uploads mappán.
• „Hiányzó munkakönyvtár.” vagy „Hiba a fájl lemezre írásakor.”: az első, ideiglenes mentés hiúsult meg. Ez szerveroldali hiba; írjon ügyfélszolgálatunknak.
• „The uploaded file exceeds the upload_max_filesize directive in php.ini.” (ezt a WordPress angolul írja ki): a fájl túl nagy. Erről a feltöltési korlátról szóló cikk ír.

A WordPress az áthelyezés hibáját elnémítja, ezért a PHP-naplóban többnyire nincs nyoma. Az okot az alábbi próbával gyorsabban megtalálja.

1. Próbáljon írni a mappába

A cPanel Terminal (Speciális csoport) vagy SSH a saját felhasználójaként fut, pontosan úgy, mint a PHP. Írja be a hibaüzenetben szereplő mappát:

touch ~/public_html/wp-content/uploads/2026/10/.irasteszt && echo IRAS OK

A lehetséges válaszok:

• IRAS OK: a mappa írható, az ok máshol van (lásd a 4. és 5. lépést). Törölje a tesztfájlt: rm ~/public_html/wp-content/uploads/2026/10/.irasteszt.
• Permission denied: jogosultsági hiba, folytassa a 2. lépéssel.
• Disk quota exceeded: betelt a tárhely, lásd a 3. lépést.
• No such file or directory: a WordPress máshová ír, mint gondolja, lásd a 4. lépést.

A teszt-webhelyünkön egy írásvédett (555) hónapmappával pontosan ezt a hibaüzenetet kaptuk, és a 755 visszaállítása után a feltöltés azonnal működött.

2. Jogosultság és tulajdonos

Nézze meg az útvonal minden mappáját:

cd ~/public_html
stat -c '%U:%G %a %n' wp-content wp-content/uploads wp-content/uploads/2026 wp-content/uploads/2026/10

Rendben lévő eredmény:

felhasznalonev:felhasznalonev 755 wp-content
felhasznalonev:felhasznalonev 755 wp-content/uploads
felhasznalonev:felhasznalonev 755 wp-content/uploads/2026
felhasznalonev:felhasznalonev 755 wp-content/uploads/2026/10

Ha a tulajdonos az Ön felhasználója, de a jog nem 755 (például 555 vagy 500), állítsa vissza a mappákat 755-re, a fájlokat 644-re:

find ~/public_html/wp-content/uploads -type d -exec chmod 755 {} +
find ~/public_html/wp-content/uploads -type f -exec chmod 644 {} +

SSH nélkül ugyanezt a cPanel Fájlkezelő felületén végezheti el: jelölje ki a mappát, és az Engedélyek gombbal állítsa be a 755 értéket. A jogosultságokról a chmod és chown cikk ír bővebben.

Ha a tulajdonos nem az Ön felhasználója (például root), a jogosultságot Ön nem tudja megváltoztatni, a chmod az Operation not permitted hibát adja. Ez többnyire egy kézzel, rendszergazdaként végzett költöztetés után fordul elő. Írjon ügyfélszolgálatunknak, és küldje el a stat parancs kimenetét: visszaadjuk a mappákat az Ön felhasználójának. Számolja meg az érintett fájlokat is, hogy tudjuk, mekkora a baj:

find ~/public_html/wp-content/uploads ! -user "$(whoami)" | wc -l

A 777 jogosultságot ne használja „megoldásként”: a szerveren futó más folyamatoknak is írást engedne a mappájába, és elfedi a valódi okot.

3. Betelt a tárhely vagy a fájlok korlátja

Ha a tárhely betelt, a hónap mappája létezik, de a rendszer nem enged több írást, és a WordPress ugyanezt a hibát adja. A cPanel kezdőlapjának jobb oldalán, a Statistics panelen a Lemezhasználat és a Fájlhasználat sor mutatja, hol tart a csomag korlátjához képest.

Tipikus jel, ha a kis képek még feltöltődnek, a nagyok már nem. Szabadítson fel helyet (régi mentések, gyorsítótár-mappák, nagy levelezőfiókok), a nagy mappákat a Lemezhasználat felületén találja meg. A fájlok számának korlátjáról az inode-okról szóló cikk ír. Ha a webhely kinőtte a csomagot, váltson nagyobbra.

4. Hová ír valójában a WordPress?

A WordPress a feltöltési mappát az upload_path beállításból, a wp-config.php fájl UPLOADS állandójából és a bővítmények szűrőiből számolja ki. Egy költöztetés után gyakran a régi tárhely abszolút útvonala marad bent. Kérdezze meg a WordPresst:

cd ~/public_html
wp option get upload_path
wp config get UPLOADS
wp eval 'print_r( wp_upload_dir() );'

Rendben lévő webhelyen az upload_path üres, az UPLOADS nincs megadva (a parancs ezt hibaként jelzi, ez a normális), a wp_upload_dir() pedig a saját mappáját mutatja:

[path] => /home/felhasznalonev/public_html/wp-content/uploads/2026/10
[basedir] => /home/felhasznalonev/public_html/wp-content/uploads

Ha a basedir egy másik felhasználó vagy egy régi mappa útvonala, irányítsa vissza a webhelyet a saját mappájára:

wp option update upload_path ""
wp option update upload_url_path ""

Ha a wp config get UPLOADS útvonalat írt ki, törölje: wp config delete UPLOADS. SSH nélkül az upload_path beállítást a /wp-admin/options.php oldalon is megtalálja (a rejtett beállítások listája), ott ürítse ki a mezőt.

5. Bővítmény vagy többwebhelyes hálózat

Egy bővítmény (például egy médiakiszervező vagy tagsági bővítmény) a feltöltési mappát máshová irányíthatja. Hasonlítsa össze az útvonalat bővítményekkel és nélkülük:

wp eval 'echo wp_upload_dir()["path"], PHP_EOL;'
wp eval 'echo wp_upload_dir()["path"], PHP_EOL;' --skip-plugins

Ha a két sor eltér, a bővítmény mappájának is léteznie kell, és az Ön felhasználójáé kell legyen. Többwebhelyes telepítésnél minden aloldal a wp-content/uploads/sites/<azonosító>/ mappába ír; a hibás aloldal mappáját így kérdezheti le: wp --url=bolt.pelda.hu eval 'echo wp_upload_dir()["path"], PHP_EOL;'.

Ellenőrzés

• Az admin felületen a Média › Médiatár oldalon töltsön fel egy kis képet; a bélyegképnek hibaüzenet nélkül kell megjelennie.
• Vagy parancssorból:

cd ~/public_html
wp media import ~/proba.jpg --title="Feltöltési teszt" --porcelain

A válasz az új melléklet azonosítója; a mappában megjelenik a kép és a bélyegképei. A tesztképet utána törölje: wp post delete <azonosító> --force.

Ha a hiba minden visszaállítás vagy szinkronizálás után visszatér, a fájlokat másoló folyamat hozza létre rossz tulajdonossal a mappákat; ebben az esetben is írjon nekünk, és együtt megkeressük az okot.