Laravel Storage Link Çalışmıyor: 404 ve İzin Hataları Nasıl Çözülür?

Laravel projelerinde yüklenen dosyalar storage/app/public altında durduğu halde tarayıcıdan açılmıyorsa ilk bakılan yer genellikle php artisan storage:link oluyor. Komut başarılı mesajı verse bile web kökü, symlink izni veya dosya sahipliği yanlışsa sonuç yine 404 olabilir.

Normal yapıda şu bağlantı oluşur:

public/storage -> storage/app/public

Proje kökünde kontrol etmek için:

php artisan storage:link
ls -la public | grep storage
readlink -f public/storage

Bağlantı yanlış hedefe gidiyorsa önce mevcut symlink’i kaldırıp yeniden oluşturabilirsiniz. Gerçek klasörü yanlışlıkla silmemek için ls -la çıktısını görmeden rm komutu çalıştırmamak önemli.

Karşılaştığım yaygın nedenler:

- Alan adının document root’u Laravel’in public klasörüne bakmıyor
- Daha önce farklı dizinde oluşturulmuş kırık symlink var
- Hosting sağlayıcısı sembolik bağlantıyı kısıtlıyor
- Apache Options FollowSymLinks izni vermiyor
- Nginx yapılandırması /storage yolunu engelliyor
- Web sunucusu kullanıcısının dosyaları okuma yetkisi yok
- Uygulama URL’si HTTP/HTTPS veya alt dizin nedeniyle yanlış

İzinleri düzeltirken her şeye 777 vermek yerine web sunucusunun çalıştığı kullanıcı ve grubu belirlemek gerekiyor. Laravel’in yazması gereken klasörler genellikle storage ve bootstrap/cache:

sudo chown -R www-data:www-data storage bootstrap/cache
sudo find storage bootstrap/cache -type d -exec chmod 775 {} \;
sudo find storage bootstrap/cache -type f -exec chmod 664 {} \;

www-data adı AlmaLinux veya cPanel sunucusunda farklı olabilir; komutu aynen kopyalamadan ortamınıza göre değiştirin. Paylaşımlı hostingte sahiplik işlemi için destek gerekebilir.

Uygulama tarafında dosya URL’sini elle birleştirmek yerine Laravel’in disk yapılandırmasına uygun Storage::url() kullanmak daha sağlıklı. .env içindeki APP_URL değiştiyse config cache’i de temizlemek gerekebilir:

php artisan optimize:clear

CDN veya Cloudflare kullanılıyorsa eski 404 cevabı cache’lenmiş olabilir. Gizli sekme veya doğrudan origin testi burada yardımcı oluyor.

Çok sunuculu yapılarda yerel storage kullanımı ayrıca düşünülmeli. Kullanıcı bir sunucuya dosya yükleyip sonraki istekte başka sunucuya düştüğünde dosya bulunamayabilir. Böyle bir yapıda S3 uyumlu ortak depolama ve doğru disk ayarı daha mantıklıdır. Tek sunucuda bile deploy işleminin symlink’i yeniden oluşturup oluşturmadığını kontrol etmek, her yayından sonra çıkan sürpriz 404 hatalarını önler.

Sizde storage:link komutu hata mı veriyor, yoksa bağlantı oluştuğu halde dosya mı açılmıyor? Sunucu türünü ve ls -la public/storage çıktısını paylaşabilir misiniz?