Ein Verzeichnis kann nicht als "root" gelöscht werden, auch nicht nach einem "chattr -i"

Question

Ein Verzeichnis kann nicht als "root" gelöscht werden, auch nicht nach einem "chattr -i"

824

Harry 2016-12-24 в 04:24

Ich versuche, ein Verzeichnis zu löschen foo, und bin völlig aus der Sache heraus, um zu versuchen.

Hinweis: Ich weiß, ich sollte keine LxD-Container mit löschen rm, aber ich hatte den Inhalt dieses Verzeichnisses schon vorher durcheinander gebracht und kann dies rmjetzt tun .)

Beachten Sie, dass das übergeordnete Element foo(dh das containersVerzeichnis) über Schreibberechtigungen verfügt.

[root@box /var/lib/lxd]$ ls -l drwx--x--x 1 root root 74 Dec 24 09:09 containers <snip>  [root@box /var/lib/lxd]$ cd containers/ [root@box /var/lib/lxd/containers]$ ls -l <snip> drwxr-xr-x+ 1 231072 231072 0 Dec 24 09:13 foo  [root@box /var/lib/lxd/containers]$ ls -l foo total 0  [root@box /var/lib/lxd/containers]$ lsattr  <snip> ---------------- ./foo  [root@box /var/lib/lxd/containers]$ lsattr -d foo ---------------- foo  [root@box /var/lib/lxd/containers]$ /bin/rm -rf foo /bin/rm: cannot remove 'foo': Operation not permitted  [root@box /var/lib/lxd/containers]$ chattr -R -ia foo [root@box /var/lib/lxd/containers]$ lsattr -d foo ---------------- foo  [root@box /var/lib/lxd/containers]$ /bin/rm -rf foo /bin/rm: cannot remove 'foo': Operation not permitted  [root@box /var/lib/lxd/containers]$ ls -l <snip> drwxr-xr-x+ 1 231072 231072 0 Dec 24 09:13 foo

Sogar eine chown -R root.root foohilft nicht!

Überraschend ist, lsattrdass keine zusätzlichen Attribute angezeigt werden foo, und zwar sowohl zu Beginn als auch nach dem chattrBefehl. Also, warum ls -l foozeigte und zeigt es die Liste +nebenan foo?

Ich verwende Ubuntu 16.04 mit ext4fs, mit den neuesten Updates ab heute.

BEARBEITEN : Das Dateisystem ist btrfs und NICHT ext4fs. Dies ist eine externe USB-Festplatte, die ich auf meinem Host installiere /var/lib/lxd.

3

Hast du "chown root: root foo" und "chmod 555 foo" ausprobiert, damit du es löschen kannst? Scheint mir, dass der Ordner kaputt ist. : P Nicht dass es viel hilft. cengbrecht vor 7 Jahren 0

@cengbrecht Ich hatte vorher "chown" ausprobiert, aber diesmal funktionierte es auch nicht "chmod". Übrigens siehe meinen EDIT in einer Sekunde. Harry vor 7 Jahren 0

Was ist mit ls-Lah cengbrecht vor 7 Jahren 0

was ist mit fsck, hast du die festplatte überprüft? (Wirf einfach, was ich meinen Servern angetan habe) cengbrecht vor 7 Jahren 0

Nee. `btrfsck` hat keine Fehler gemeldet. "ls -lah" im übergeordneten Element von "foo" meldet 0 Byte für "foo"; Innerhalb von `foo` werden nur` .`- und `..`-Verzeichnisse aufgeführt, wobei für` .` eine zusätzliche Berechtigung (+) enthalten ist. Harry vor 7 Jahren 0

1 Antwort auf die Frage

4

Accepted Answer · 2016-12-24 10:16:08

Meine Wette ist, dass Ihr Verzeichnis tatsächlich ein Btrfs-Subvolume ist. Ich habe einen Test gemacht. Wenn ich versuche, rmmein Test-Subvolumen zu testen, bekomme ich "Operation nicht erlaubt".

Wenn ich recht habe, sollte Folgendes in Ihrem Fall funktionieren:

sudo btrfs subvolume delete foo

Ich verstehe, dass Ihr Verzeichnis bereits leer ist, aber im Allgemeinen müssen Sie es zuvor leeren.

Weitere Erklärung auf Wunsch:

Ein Subvolume ist ein Teil des Dateisystems mit einer eigenen und unabhängigen Datei- / Verzeichnishierarchie. Subvolumes können Dateierweiterungen gemeinsam nutzen.

Sie können mehr vom btrfs Wiki lernen . Die Hauptgründe, aus denen ein Subvolume anstelle eines regulären Verzeichnisses erstellt werden kann, sind:

Ein Subvolume kann gemountet werden, da es sich um ein separates Dateisystem mit eigenen Optionen handelt (vergleiche: Sie können zwar ein reguläres Verzeichnis mit Bind-Mount mounten, es muss jedoch in einem bereits gemounteten Dateisystem vorhanden sein; das Btrfs-Subvolume kann leicht als Root-Dateisystem gemountet werden /);
Es kann ein Subvolume-Snapshot erstellt werden, bei dem es sich um ein separates Subvolume handelt, das anfänglich alle Dateierweiterungen mit dem Quell-Subvolume gemeinsam nutzt.

Praxisbeispiel:

Mein btrfs-Dateisystem hat die folgende interne Struktur (bedenken Sie, dass diese Struktur sich von der Verzeichnisstruktur unterscheidet, die das System sieht; dazu gehören Mountpoints):

/ # btrfs root filesystem mounted as /mnt/ssd/ @ # a subvolume I use as the root filesystem (mounted as /) @backups @-20161215-1-working # a snapshot of @ just in case

Nehmen wir an, ich möchte mich mit meinem System beschäftigen. Als Vorsichtsmaßnahme erstelle ich zunächst einen Schnappschuss:

cd /mnt/ssd/@backups sudo btrfs subvolume snapshot ../@ @-20161224-1-just_in_case

Ich mache es aus meinem Arbeitssystem heraus und es dauert keine Zeit. Es nimmt anfangs auch keinen Speicherplatz in Anspruch. Der zusätzliche Speicherplatz wird später zugewiesen, wenn sich die entsprechenden Dateien und Verzeichnisbäume unterscheiden.

Als nächstes kann ich sogar mein System, das sich im @Subvolume befindet, brechen. Solange das @backups/@-20161224-1-just_in_caseSubvolume intakt ist, kann ich durch @dieses Backup ersetzen, als wäre nichts passiert. Im schlimmsten Fall muss ich von einer Live-Distribution booten. Wenn mein Bootloader (GRUB2) weiterhin funktioniert, kann ich den Eintrag zur Boottime bearbeiten und temporär @backups/@-20161224-1-just_in_caseanstelle von @Subvolume als Root-Dateisystem verwenden. Dann mache ich aus dem wieder funktionierenden System:

cd /mnt/ssd/ sudo btrfs subvolume delete @ # I may have to empty it first sudo btrfs subvolume snapshot @backups/20161224-1-just_in_case @

Danach starte ich neu. Das System wird wiederhergestellt.

Ein Verzeichnis kann nicht als "root" gelöscht werden, auch nicht nach einem "chattr -i"

1 Antwort auf die Frage

Weitere Erklärung auf Wunsch:

Praxisbeispiel:

Verwandte Probleme