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?