Errori di completamento della scheda: bash: impossibile creare il file temporaneo per here-document: spazio vuoto sul dispositivo


41

Quando utilizzo la barra delle schede, continuo a ricevere questo errore:

bash: impossibile creare il file temporaneo per here-document: spazio sul dispositivo non disponibile "

Qualche idea?

Ho fatto delle ricerche e molte persone parlano del file / tmp, che potrebbe avere un overflow. Quando eseguo df -hottengo:

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

Sembra che la directory / dev / data stia per esplodere, tuttavia se suggerisco:

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

Sembra che sia vuoto.

Sono nuovo in Debian e non so davvero come procedere. In genere accedevo a questo computer tramite ssh. Oltre a questo problema ne ho molti altri con questo computer, potrebbero essere correlati, ad esempio ogni volta che voglio inserire il mio utente usando la GUI (con root funziona) ottengo:

Xsession: avviso: impossibile scrivere su / tmp: Xsession potrebbe uscire con un errore


2
Volete eseguire qualcosa del genere du -hxd1 /, no du /dev/sda2. /dev/sda2non esiste davvero sul disco.
muru,

Risposte:


20

Il tuo file system di root è pieno e quindi anche la tua directory temporanea (/ tmp e / var / tmp). Molti script e programmi richiedono spazio per i file di lavoro, persino per bloccare i file. Quando / tmp è non scrivibile accadono cose brutte .

Devi capire come hai riempito il filesystem. In genere questo accade in / var / log (controlla che stai ciclando i file di registro). O / tmp potrebbe essere pieno. Ci sono molti, molti altri modi che un disco può riempire, tuttavia.

du -hs /tmp /var/log

Potresti voler ripetere la partizione per dare a / tmp la propria partizione (questo è il vecchio modo di farlo, ma se hai un sacco di disco va bene), o mappalo in memoria (che lo renderà molto veloce ma inizierà a causare problemi di scambio in caso di esagerazione con i file temporanei).


Ciao, ho esaminato entrambi i comandi che suggerisci e direi che entrambi / tmp e / var / log sono abbastanza vuoti: rispettivamente 60K e 49M.
lucasrodesg,

1
Ciao di nuovo. Finalmente l'ho capito. Non so perché ho inserito tutti i contenuti di owncloud in / var. Funziona di nuovo!
lucasrodesg,

16

Potresti anche aver perso l'accesso in scrittura alla /tmp/directory.

Dovrebbe apparire così:

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

È possibile correggere le autorizzazioni in questo modo:

chmod a+rwxt /tmp

Questo ha funzionato per me!
Joseph Chambers,

3
Questo è un uso inutile di grep. Prova ls -ld /tmpinvece.
un CVn il

hai appena fermato un attacco di panico quasi completo ... merita un voto per me
sbeskur

11

Se qualcuno arriva con questo errore quando il disco non è pieno, assicurati di controllare non solo dfma anche df -i. Esiste un numero fisso di inode su un filesystem e ogni file ne ha bisogno. Se hai solo un sacco di piccoli file, è molto facile per il tuo filesystem riempire con questi piccoli file mentre c'è ancora molto spazio sull'unità quando esegui df.


Questo è stato il problema che ho avuto! Continuavo a cercare quello che occupava lo spazio. Questo non era affatto il problema. Avevo esaurito completamente gli inode. /dev/root 4980000 4980000 0 100% /Forse il sistema dovrebbe rispondere con un messaggio di errore appropriato?
ˆᵛˆ

3

Stavo ricevendo un errore, quindi ho visto

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

Sono stato in grado di confermare questo,

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

2

Il modo più rapido per individuare le cartelle troppo piene è restringendo le dimensioni del file della cartella in livelli dalla cartella principale. Si inizia con la cartella principale tramite:

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

Quindi - ORA aumenti la profondità, ovvero i livelli seguenti:

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

OPPURE - più veloce - vedi quale cartella ha consumato più spazio su disco e fai lo stesso su questa cartella:

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

Una volta trovato, basta rimuovere quello:

rm -rf <path to overfull-folder>

1
con molti file di output è bello ordinarli per dimensione con sudo du -h --max-depth=1 / | sort -h(file più grandi in fondo o sort -hrper file più grandi in alto)
wranvaud

0

Per il mio caso di questo stesso errore, si trattava di un problema di gabbia poiché questo server era su CloudLinux, risolto con cagefsctl --remount username


-2

Questo perché lo spazio su disco non è sufficiente, è necessario ripulire i file di grandi dimensioni o ripulire il processo che occupa spazio:

  1. df -h Visualizza lo spazio sul disco rigido
  2. du -sh /* Visualizza quale directory è la più grande, passo dopo passo per trovare file di grandi dimensioni
  3. du -h --max-depth=1 trova il file più grande

Questo sembra rigurgitare la risposta di Agile Bean da giugno 2018.
Tripleee
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.