WordPress’te dosya izinleri: Hangi klasör ne olmalı?

WordPress sitelerinde “sayfa açılmıyor”, “eklentiler güncellenmiyor” veya “uploads klasörüne yazılamıyor” sorunları çoğunlukla dosya izinleri (permissions) ve sahiplik (ownership) kaynaklıdır. Bu yazıda web sunucusu (Apache/Nginx) ve PHP’nin hangi dizine yazması gerektiğini netleştirerek, hangi dizinde hangi izin mantığının doğru olduğunu anlatacağım. Ayrıca chmod değerlerinin ne işe yaradığını, WordPress güvenliğinde “en az yetki” yaklaşımını ve sık yapılan hataları karşılaştırmalı şekilde ele alacağız.

WordPress dosya izinleri neden kritik? (Sadece “chmod yap” değil)

WordPress, kurulum sırasında bazı klasörlere dosya yazar: eklenti/tema güncellemeleri, görsel yükleme (uploads), otomatik yedekleme dosyaları, cache üretimi ve bazı durumlarda geçici dosyalar. Bu yazma işlemi için web sunucusunun PHP süreci belirli klasörlerde yazma yetkisine ihtiyaç duyar.

Yanlış izinler iki tip sorun üretir: - Kötü senaryo (yazılamıyor): Web sunucusu uploads veya cache’e yazamadığı için güncelleme başarısız olur. - Riskli senaryo (fazla izin): Yanlışlıkla world-writable (herkes yazabilir) yetkileri verirseniz, saldırı yüzeyi büyür.

Bu nedenle hedefiniz şudur: WordPress’in yazması gereken dizinlerde yazma yetkisi, geri kalan yerlerde kısıtlı yetki.

WordPress’te “doğru” sahiplik (ownership) nasıl olmalı?

Önce chmod değil, sahipliği doğru kuralım. WordPress dosyalarının sahibi genellikle kontrol panelinizde kullandığınız kullanıcıdır (ör. youruser). Web sunucusunun yazabilmesi için iki yaklaşım kullanılır:

1) Dosyalar ve dizinler aynı kullanıcıya ait olur (ör. www-data değil, sitenin servis kullanıcısı). 2) Dosyalar bir kullanıcıya ait olur ama web sunucusu aynı gruba dahildir; gerektiğinde grup yazma izni verilir.

Linux’ta tipik senaryolar: - Debian/Ubuntu: Apache/PHP çoğu kurulumda www-data kullanıcı grubunda çalışır. - CentOS/RHEL: Apache çoğunlukla apache veya nginx ile ilişkilidir.

Kontrol komutu örnekleri (sizde dizin yolu farklı olabilir): - WordPress kökü için: - ls -lah /var/www/siteadi - Her şeyi recursive görmek isterseniz: - find /var/www/siteadi -maxdepth 3 -type d -o -type f | head

Burada kritik alan: dosyaların owner ve group değerleri. Uygun bir kural şudur: - WordPress dosyaları: normalde owner sizin admin kullanıcı, group web sunucu grubu - Web sunucusunun yazması gereken yerler: group yazabilir

Hangi dizin ne olmalı? (Tipik WordPress klasörleri için net tablo)

Aşağıdaki tablo, Linux üzerinde tipik bir WordPress kurulumunda pratik “hedef izinleri” özetler. Kullanılan değerler chmod mantığına dayanır.

Not: Değerler “genel rehber”dir; dosya sistemi (NFS gibi), hosting sağlayıcısının güvenlik politikası ve web sunucusu kullanıcısı (ör. www-data) sonucu etkiler. Yine de doğru mantıkla ilerlediğinizde sorunların büyük kısmı çözülür.

Önerilen izin şablonu (chmod)

Neden dosya için 644, dizin için 755 (ve uploads için 775)?

• 644: Dosya okuma/yürütme açısından güvenli. Web sunucusu dosyayı okuyabilir, yazması genelde gerekmez.
• 755: Dizin içinde okuma ve listeleme serbest, ancak herkes yazamaz.
• 775: uploads gibi yazma gerektiren dizinlerde grup yazabilir. Bu, “web sunucusu grubu yazabilsin ama world yazamasın” yaklaşımıdır.

Bu yaklaşım, WordPress’in yazması gereken yeri yazılabilir tutarken gereksiz yere herkese yazma izni vermemeyi sağlar.

En sık görülen hatalar ve net çözüm adımları

1) uploads’a yazılamıyor (Eklenti/yükleme başarısız)

Belirti örnekleri: - Medya yüklerken hata - Eklenti güncellemesi başarısız - “Permission denied” (izin reddedildi)

Kontrol adımları: - ls -lah wp-content - ls -lah wp-content/uploads

Hedef: - uploads dizini: 775 ve doğru group - uploads alt dosyalar çoğunlukla 664 veya 644 olabilir; pratikte site stabilitesi için çoğu kurulum 644 dosya + 775 dizin şeklinde yürür.

2) “World-writable” güvenlik riski

Eğer uploads veya benzeri dizinler 777 ise herkes yazabilir. Bu değer saldırı durumunda riski yükseltir.

Net hedef değerler: - 777 yerine 775 kullanın (gruba yazma). - Mümkünse web sunucusunun çalıştığı grup ile ownership eşleştirin.

3) Güncellemeler çalışıyor ama sayfa açılmıyor

Bazı senaryolarda izinler tamam olsa bile sahiplik bozuk olur. WordPress çekirdek dosyalarının owner/grubu değiştiğinde PHP bazı dosyalara erişemez.

Kontrol komutu: - WordPress kökünde owner/grup farkını görün: ls -lah

Çözüm yaklaşımı: - Sadece gereken dizinleri yazılabilir yapın. - Gereksiz recursive chmod -R uygulamalarını minimumda tutun.

Kontrol paneli vs SSH: izin düzeltme stratejisi

Bir hosting ortamında iki yol var: - SSH ile manuel düzeltme: En esnek yöntem. - Kontrol paneli (File Manager) ile izin set etme: Daha hızlı ama recursive detay kaçabilir.

Özellikle 20+ dosya seviyesinde recursive izin güncellemesi gerekiyorsa SSH daha net sonuç verir.

SSH ile “hedefe yönelik” izin düzeltme örneği

Aşağıdaki komutlar eğitim amaçlı şablondur. Kendi dizin yolunuza ve kullanıcı/grubunuza göre uyarlayın.

1) WordPress kökündeki dizinler 755, dosyalar 644 - find /var/www/siteadi -type d -exec chmod 755 {} \; - find /var/www/siteadi -type f -exec chmod 644 {} \;

2) uploads yazma izni - find /var/www/siteadi/wp-content/uploads -type d -exec chmod 775 {} \; - find /var/www/siteadi/wp-content/uploads -type f -exec chmod 664 {} \;

Bu adımda kritik nokta: Sadece chmod yetmez; ownership de tutarlı olmalı. Aksi halde chmod yaptıktan sonra bile PHP “yine yazamaz”.

Dosya izinlerini doğrulamak için pratik testler

İzinleri ayarladıktan sonra “hemen çalışıyor mu?” sorusunu netleştirmek gerekir.

1) WordPress’te güncelleme/medya testi

• wp-admin üzerinden eklenti güncellemesini deneyin.
• Medya ekleyin.

Bu iki test genellikle izin problemlerini en hızlı ortaya çıkarır.

2) Web sunucusu hata loglarını kontrol edin

• Apache/Nginx hata logu yolu hostinge göre değişir.
• Aradığınız ifade genellikle: Permission denied, failed to open stream, Unable to create directory.

3) Hosting sağlayıcısı politikası

Bazı firmalar (özellikle güvenlik odaklı yönetilen hostinglerde) izinlerin otomatik yönetilmesine izin vermez. Bu durumda doğru yaklaşım: - Sağlayıcının dokümantasyonunda belirtilen izin şablonunu kullanmak - Gerekirse otomasyon/kurulum botu ile yetki yönetimi sağlamak

İzinleri ayarlarken “en az yetki” kuralı

Güvenlik ve stabilite için şu prensibi uygulayın: - Sadece yazması gereken dizinlerde yazma yetkisi ver. - Dizinlerde 775 bandı genelde yeterlidir. - Dosyalarda 644 yeterlidir. - 777 kullanımını bir çözüm değil, acil hata göstergesi olarak görün.

Ayrıca cache eklentileri (ör. hız/performans eklentileri) bazı dizinlerde geçici dosya oluşturur. Bu dizinlerin (ör. wp-content/cache) izinleri doğru olmazsa “site yavaşlıyor” veya “cache temizlenemiyor” gibi semptomlar ortaya çıkar.

Net kontrol listesi: “izinler doğru mu?”

Aşağıdaki listeyi tek tek işaretleyin: - [ ] WordPress kök dizin ve alt kod dizinleri 755 (dizin) / 644 (dosya) - [ ] wp-content/uploads dizini 775 ve web sunucusunun çalıştığı grup ile uyumlu ownership - [ ] wp-content/themes, wp-content/plugins kod dizinleri gereksiz yazılabilir değil - [ ] wp-content/cache veya benzeri cache dizinleri yazma gerektiriyorsa 775 - [ ] Güvenlik için 777 yok - [ ] Güncelleme ve medya yükleme testleri başarılı - [ ] Hata loglarında Permission denied kalmıyor

Sonuç: Dosya izinlerini “gereken yere yazma” mantığıyla sabitleyin

WordPress’te dosya izinleri doğru kurulmadığında sorun “rastgele” görünür; oysa kök neden çok büyük oranda uploads/cache gibi yazma gerektiren dizinlerin yanlış sahiplik veya chmod değerleridir. Önce owner/group uyumunu netleştirin, ardından kök ve kod dizinlerini 755/644 şablonunda tutun; yalnızca wp-content/uploads (ve yazma gerektiren cache/upgrade dizinleri) için 775 yaklaşımını uygulayın. Bu adımları uyguladıktan sonra eklenti güncelleme + medya yükleme testini yapın; loglarda izin reddi kalmıyorsa sisteminiz doğru yöndedir.