Son gözden geçirme: Eylül 2026 · Ubuntu 24.04 resmî dokümanına göre
Hızlı çözüm
No space left on device hatası, dosyanın yazılacağı bölümde ya boş alanın ya da boş inode’un bittiğini gösterir; önce hangisinin bittiğini bulup sonra yer açarsınız.
df -h ile dolu bölümü, df -i ile inode doluluğunu kontrol edin.du ile yer kaplayan klasörü bulun (çoğunlukla /var/log, /var/lib/docker, yedek klasörleri).journalctl --vacuum-size ile küçültün, apt clean ile paket önbelleğini boşaltın.df boş gösteriyorsa lsof +L1 ile silinmiş ama açık tutulan dosyaları bulun.| Panel | Yok — komutlar SSH ya da tarayıcı terminalinden çalıştırılır |
|---|---|
| Sistem | Ubuntu 22.04/24.04, Debian 12 (VPS/VDS) |
| Yetki | Sunucunuzun root ya da sudo yetkili kullanıcısı |
| Narhost ürünü | VPS Sunucu, VDS Sunucu |
Başlamadan önce
Linux’ta bir dosya yazılırken iki kaynak birden gerekir: veri blokları için boş alan ve dosyanın kaydı için boş bir inode. Hangisi biterse bitsin çekirdek aynı ENOSPC hata kodunu döndürür; MySQL tablo yazamaz, PHP oturum dosyası oluşturamaz, apt paket açamaz ve web sunucusu 500 vermeye başlar.
Alan tükenmesinin olağan kaynakları büyüyen günlük dosyaları, systemd-journal kayıtları, sunucuda biriken yedek arşivleri ve kullanılmayan Docker imajlarıdır. İnode tükenmesi ise milyonlarca küçük dosyadan gelir: PHP oturum klasörü, uygulama önbelleği, kuyruğa takılmış e-postalar. Üçüncü ve en şaşırtıcı durum, silinmiş ama bir süreç tarafından hâlâ açık tutulan dosyadır: du onu göremez, df ise alanı dolu gösterir.
-h alanı okunur birimlerle, -i inode kullanımını gösterir.
df -h
df -iBeklenen sonuç: Use% sütunu %100’e yakınsa alan, IUse% %100’e yakınsa inode tükenmiştir.
-x seçeneği taramayı aynı dosya sisteminde tutar.
sudo du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -15
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -rh | head -15Beklenen sonuç: en büyük klasörler üstte sıralanır; şüpheli klasöre aynı komutla bir seviye daha inin.
sudo du --inodes -x -d 1 / 2>/dev/null | sort -rn | head -15Beklenen sonuç: dosya sayısı en yüksek klasör üstte görünür; oturum ya da önbellek klasörüyse eski dosyaları uygulamanın kendi temizleme aracıyla silin.
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
sudo apt clean
sudo apt autoremove --purgeBeklenen sonuç: journalctl silinen arşiv dosyalarını ve açılan alanı yazar; df -h boş alanın arttığını gösterir.
rm ile silinirse alan geri gelmez; içeriği sıfırlayın:
sudo truncate -s 0 /var/log/ornek-uygulama.log+L1 bağlantı sayısı sıfır olan, yani silinmiş dosyaları listeler.
sudo lsof +L1Beklenen sonuç: COMMAND sütununda dosyayı tutan süreç görünür; o servisi yeniden başlattığınızda (sudo systemctl restart nginx gibi) alan serbest kalır.
Dikkat
docker system prune -a çalışmayan konteynerleri ve kullanılmayan tüm imajları siler; önce docker system df ile neyin yer kapladığına bakın. Veritabanı dosyalarını (/var/lib/mysql) ve /boot içeriğini elle silmeyin.
Sonuç
df -h ve df -i kullanım oranını %90’ın altında gösteriyor, hata veren işlem (paket kurulumu, veritabanı yazması, dosya yükleme) yeniden denendiğinde tamamlanıyorsa sorun çözülmüştür. Kalıcı çözüm için günlük döndürme (logrotate) ayarlarını ve yedeklerin sunucu dışına taşınmasını kontrol edin.
find komutlarını kullanın.Narhost desteği
VPS/VDS yönetimsizdir, sunucu içindeki temizlik sizin sorumluluğunuzdadır; sunucuya hiç erişemiyorsanız talep açın. Talebe şunları ekleyin: sunucu adı, No space left on device hatasının geçtiği tam çıktı, df -h ve df -i çıktıları, hatanın başladığı saat ve denediğiniz adımlar.
Sonraki adımlar
İnode’lar bitmiş olabilir; df -i çıktısında IUse% değerine bakın. İkinci olasılık silinmiş ama açık tutulan dosyalardır, lsof +L1 bunları listeler.
Yalnız silinmiş ama açık tutulan dosyalar için açar, çünkü süreçler kapanınca bu dosyalar serbest kalır. Günlük, yedek ve imaj kaynaklı doluluğu çözmez; o dosyaların temizlenmesi gerekir.
Evet. /etc/systemd/journald.conf dosyasında SystemMaxUse= değeri verip systemd-journald servisini yeniden başlattığınızda günlükler bu boyutun üzerine çıkmaz.
Bu makale sorununuzu çözdü mü?
Geri bildiriminiz için teşekkürler.
Çözemediniz mi?
Teknik ekibimiz sunucu tarafındaki ayarları sizin için kontrol edebilir. Destek talebinizde alan adınızı ve aldığınız hata metnini paylaşmanız süreci hızlandırır.
