Datei kann nicht als root gelöscht werden

444
Adam Griffin

Das regelmäßige System-Update (Linux Mint 19) schlug mit dem Fehler fehl, dass eine Sicherung der Datei nicht möglich ist. Die Datei hat ein sehr seltsames Verhalten von Inhabern und Gruppen sowie ungerade lsattr. Datei kann nicht als root gelöscht werden.

$ ls -lah total 64K drwxr-xr-x 2 root root 4.0K Sep 14 00:41 . drwxr-xr-x 15 root root 4.0K Jul 20 06:18 .. -rw-r--r-- 1 root root 18K Jul 17 03:41 cs-xlet-danger.svg -rw-r--r-- 1 root root 13K Jul 17 03:41 cs-xlet-running.svg -rw-r--r-- 1 root root 19K Jul 17 03:41 cs-xlet-system.svg -rw-r--r-- 1 2558197760 2848915456 0 Jul 17 03:41 cs-xlet-update.svg $ sudo rm -f cs-xlet-update.svg  rm: cannot remove 'cs-xlet-update.svg': Operation not permitted $ lsattr . --------------e--- ./cs-xlet-danger.svg --------------e--- ./cs-xlet-system.svg lsattr: No data available While reading flags on ./cs-xlet-update.svg --------------e--- ./cs-xlet-running.svg 

Ich starte dann eine Live-CD, um das Dateisystem zu überprüfen.

$ sudo e2fsck -f /dev/sda1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 291836/1310720 files (0.4% non-contiguous), 2935417/5242624 blocks 

Nachdem das Dateisystem als gut bestätigt wurde, mounte ich das Laufwerk und versuche, die Datei vom Live-CD-Betriebssystem (Linux Mint) zu löschen.

$ ls -lah total 64K drwxr-xr-x 2 root root 4.0K Sep 14 04:41 . drwxr-xr-x 15 root root 4.0K Jul 20 10:18 .. -rw-r--r-- 1 root root 18K Jul 17 07:41 cs-xlet-danger.svg -rw-r--r-- 1 root root 13K Jul 17 07:41 cs-xlet-running.svg -rw-r--r-- 1 root root 19K Jul 17 07:41 cs-xlet-system.svg -rw-r--r-- 1 2558197760 2848915456 0 Jul 17 07:41 cs-xlet-update.svg $ sudo rm -f cs-xlet-update.svg  rm: cannot remove 'cs-xlet-update.svg': Operation not permitted $ lsattr . --------------e--- ./cs-xlet-danger.svg --------------e--- ./cs-xlet-system.svg lsattr: No data available While reading flags on ./cs-xlet-update.svg --------------e--- ./cs-xlet-running.svg 

Schließlich versuche ich es per Inode ohne Erfolg zu löschen:

$ ls -i cs-xlet-update.svg  220926 cs-xlet-update.svg $ find . -inum 220926 -exec sudo rm -i {} \; rm: remove regular empty file './cs-xlet-update.svg'? y rm: cannot remove './cs-xlet-update.svg': Operation not permitted 

Wie kann ich diese Datei entfernen?

1
Hat das Dateisystem nicht wirklich erzwungen, ohne das Flag -f e2fsck warf einen kurzen Blick darauf und sagte, es sei nicht verschmutzt. Und war es beschreibbar (rw) montiert? Xen2050 vor 5 Jahren 0
@ Xen2050 Tolle Idee! Leider hat das nichts gefunden. Ich habe meine e2fsck-Zeile mit den -f-Ergebnissen bearbeitet. Und ja, das Dateisystem ist als rw gemountet. Adam Griffin vor 5 Jahren 0

1 Antwort auf die Frage

0
Xen2050

Nach dem Erzwingen eines fsck (mit seiner -fFlagge) und es erscheint immer noch sauber ... Die Benutzer- / Gruppennummern sind ungewöhnlich, im Allgemeinen sind sie unter 10000, denke ich, zwei Milliarden sehen nicht richtig aus und sie sind null Byte. Etwas ist komisch. Könnten einige erweiterte Attribute sein, die ebenfalls überprüft werden sollten, wenn diese nicht funktionieren.

Vielleicht versuchen Sie es mit der Auflistung nach Inode

ls -il 

und dann nach Inode löschen, mit find und rm

find . -inum [inode-number] -exec rm -i {} \; 

oder ein anderes Beispiel empfahl, einige finden "Sicherheit" und find -delete

find . -maxdepth 1 -type f -inum [inode-number] -delete 

Für noch mehr "Sicherheit" prüfen Sie zunächst, welche Datei gefunden wurde, indem Sie -delete mit dem Standard "print" weglassen.

find . -inum [inode-number] 

Wenn diese immer noch nicht funktionieren, debugfsgibt es einige Befehle, die sollten, und viele Befehle verwenden einen Inode als Argument

 rm pathname Unlink pathname. If this causes the inode pointed to by pathname to have no other references, deallocate the file. This command functions as the unlink() system call. 

oder vielleicht

 unlink pathname Remove the link specified by pathname to an inode. Note this does not adjust the inode reference counts. 

Und selbst wenn erweiterte Attribute Probleme verursachen, können Sie versuchen getfacl, sie aufzulisten und setfaclzu ändern, die -b, --remove-allOption klingt praktisch. Oder im attrPaket gibt es auch getfattrund setfattr.

Oder debugfs hat einige erweiterte Attributbefehle wie:

 ea_get [-f outfile] filespec attr_name Retrieve the value of the extended attribute attr_name in the file file‐ spec and write it either to stdout or to outfile.  ea_list filespec List the extended attributes associated with the file filespec to stan‐ dard output.  ea_set [-f infile] filespec attr_name attr_value Set the value of the extended attribute attr_name in the file filespec to the string value attr_value or read it from infile.  ea_rm filespec attr_names... Remove the extended attribute attr_name from the file filespec. 
Meine ursprüngliche Frage zeigte, dass das Löschen von Inode ebenfalls fehlgeschlagen ist. Es scheint jedoch, dass debugfs mit rm pathname funktioniert hat. Es gab keinen Grund, warum es funktionierte oder warum rm nicht funktionierte, aber es scheint, dass ich wieder im Geschäft bin. Vielen Dank! Adam Griffin vor 5 Jahren 0
Ich war mir nicht sicher, ob es nur Probleme gab. Vielleicht hatte find's `-delete` etwas anderes gemacht. Irgendwann hat es geklappt, und andere (in älteren Posts, wenn ext vielleicht weniger stabil war?) Schlugen vor, dass ein fsck nach dem Einsatz von debugfs eine gute Idee ist Xen2050 vor 5 Jahren 0