Kesalahan penyelesaian tab: bash: tidak dapat membuat file temp untuk dokumen di sini: Tidak ada ruang tersisa di perangkat

40

Saat menggunakan bilah tab, saya terus mendapatkan kesalahan ini:

bash: tidak dapat membuat file temp untuk dokumen-sini: Tidak ada ruang tersisa di perangkat "

Ada ide?

Saya telah melakukan riset, dan banyak orang berbicara tentang file / tmp, yang mungkin mengalami overflow. Ketika saya mengeksekusi df -hsaya mendapatkan:

Filesystem      Size  Used Avail Use% Mounted on 
/dev/sda2       9.1G  8.7G     0 100% /
udev             10M     0   10M   0% /dev
tmpfs           618M  8.8M  609M   2% /run
tmpfs           1.6G     0  1.6G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.6G     0  1.6G   0% /sys/fs/cgroup
/dev/sda1       511M  132K  511M   1% /boot/efi
/dev/sda4       1.8T  623G  1.1T  37% /home
tmpfs           309M  4.0K  309M   1% /run/user/116
tmpfs           309M     0  309M   0% /run/user/1000

Sepertinya direktori / dev / data akan meledak, tetapi jika saya memberi tip:

$ du -sh /dev/sda2
0   /dev/sda2

Sepertinya itu kosong.

Saya baru di Debian dan saya benar-benar tidak tahu bagaimana melanjutkan. Saya biasanya mengakses komputer ini melalui ssh. Selain masalah ini saya memiliki beberapa orang lain dengan komputer ini, mereka mungkin terkait, misalnya setiap kali saya ingin memasukkan pengguna saya menggunakan GUI (dengan root berfungsi) saya mendapatkan:

Xsession: peringatan: tidak dapat menulis ke / tmp: Xsession dapat keluar dengan kesalahan

— lucasrodesg
sumber

2

Anda ingin menjalankan sesuatu seperti du -hxd1 /, bukan du /dev/sda2. /dev/sda2tidak benar-benar ada di disk.

— muru

19

Sistem file root Anda penuh dan karenanya temp temp (/ tmp, dan / var / tmp) juga penuh. Banyak skrip dan program membutuhkan ruang untuk bekerja, bahkan mengunci file. Ketika / tmp adalah hal-hal buruk yang tidak dapat dituliskan terjadi.

Anda perlu mengetahui bagaimana Anda telah mengisi sistem file. Biasanya tempat ini akan terjadi adalah di / var / log (periksa apakah Anda bersepeda file log). Atau / tmp mungkin penuh. Ada banyak, banyak cara lain yang dapat diisi disk.

du -hs /tmp /var/log

Anda mungkin ingin mempartisi ulang untuk memberikan / tmp partisi itu sendiri (itu adalah cara jadul untuk melakukannya, tetapi jika Anda memiliki banyak disk tidak apa-apa), atau memetakannya ke dalam memori (yang akan membuatnya sangat cepat tetapi mulailah untuk menyebabkan masalah swapping jika Anda berlebihan file sementara).

— Miles Gillham
sumber

Hai, saya melihat kedua perintah yang Anda sarankan dan saya akan mengatakan bahwa / tmp dan / var / log keduanya cukup kosong: masing-masing 60K dan 49M.

— lucasrodesg

1

Halo lagi. Saya akhirnya mendapatkannya. Saya tidak tahu mengapa saya menempatkan semua konten owncloud di bawah / var. Berhasil lagi!

— lucasrodesg

16

Anda juga mungkin kehilangan akses tulis ke /tmp/direktori.

Seharusnya terlihat seperti itu:

ls -l / |grep tmp
drwxrwxrwt   7 root root  4096 Nov  7 17:17 tmp

Anda dapat memperbaiki izin seperti itu:

chmod a+rwxt /tmp

— Dothebart
sumber

Ini berhasil untuk saya!

— Joseph Chambers

3

Itu penggunaan grep yang tidak berguna. Coba ls -ld /tmpsaja.

— CVn

Anda baru saja menghentikan serangan panik hampir penuh ... layak untuk saya

— sbeskur

10

Jika ada yang datang dengan kesalahan ini ketika disk mereka tidak penuh, pastikan untuk memeriksa tidak hanya dftetapi juga df -i. Ada sejumlah inode pada sistem file, dan setiap file membutuhkan satu. Jika Anda hanya memiliki berton-ton file kecil, sangat mudah bagi sistem file Anda untuk mengisi dengan file-file kecil ini sementara masih ada banyak ruang tersisa di drive ketika Anda menjalankan df.

— Michael Speer
sumber

Ini adalah masalah yang saya miliki! Saya terus berusaha menemukan apa yang menempati ruang. Itu bukan masalah sama sekali. Saya telah sepenuhnya menggunakan inode. /dev/root 4980000 4980000 0 100% /Mungkin sistem harus merespons dengan pesan kesalahan yang sesuai?

— ᵛ

3

Saya mendapatkan kesalahan, lalu saya melihat

[  672.995482] EXT4-fs (sda2): Remounting filesystem read-only
[  672.999802] EXT4-fs error (device sda2): ext4_journal_check_start:60: Detected aborted journal

Saya bisa mengkonfirmasi ini,

mount | grep -i sda2
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro,data=ordered)

— Evan Carroll
sumber

2

Cara tercepat untuk menemukan folder Anda yang terlalu penuh adalah dengan mempersempit ukuran file folder dalam level dari folder root. Anda mulai dengan folder root dengan:

sudo du -h --max-depth=1 /

Kemudian - BAIK Anda meningkatkan kedalaman, yaitu tingkat di bawah ini:

sudo du -h --max-depth=2 /

ATAU - lebih cepat - Anda melihat folder mana yang paling banyak memakan ruang disk, dan melakukan hal yang sama pada folder ini:

sudo du -h --max-depth=1 /home/<user>/<overfull-folder>

Setelah Anda menemukannya, hapus saja yang itu:

rm -rf <path to overfull-folder>

— Kacang Agile
sumber

1

dengan banyak file keluaran, ada baiknya mengurutkan berdasarkan ukuran sudo du -h --max-depth=1 / | sort -h(file lebih besar di bagian bawah atau sort -hruntuk file lebih besar di atas)

— wranvaud

0

Untuk kasus saya dari kesalahan yang sama ini, itu adalah masalah cagefs karena server ini ada di CloudLinux, ditangani cagefsctl --remount username

— Zebouski
sumber

-2

Ini karena ruang disk tidak cukup, Anda perlu membersihkan file besar atau membersihkan proses yang menghabiskan ruang:

df -h Lihat ruang hard disk
du -sh /* Lihat direktori mana yang terbesar, langkah demi langkah untuk menemukan file besar
du -h --max-depth=1 temukan file terbesar

— zhang_kop
sumber

Ini sepertinya hanya memuntahkan jawaban oleh Agile Bean dari Juni 2018.

— tripleee