Dateien des Mountpoints verdeckt

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

--Robi 19:06, 27. Okt 2006 (CEST)robi

Problem gemountetes Filesystem verdeckt Dateien

Gelegentlich kann es vorkommen, dass sich unter einem eingehängtem Filesystem im Mountpoint noch Dateien befinden, die aber nicht sichtbar sind. So etwas kommt zB gelegentlich vor, wenn /tmp ein eigenes Verzeichnis ist und bei einem Bootvorgang einmal nicht eingehängt werden konnte, weil das Filesystem nach einem Crash korrupt war. Dann sind dort Dateien abgelegt, die später wenn das Filesystem wieder repariert und eingehängt ist, nicht mehr sichtbar sind, aber dennoch unnötigen Speicherplatz auf dem Rootfilesystem blockieren.

Im Normalfall würde man das Filesystem aushängen (umounten) und dann dort die Dateien löschen, danach wieder mounten und fertig. Das wird aber im laufenden Betrieb nicht mit allen Filesystemen funktionieren. Man denke nur an /var oder /usr dazu müsste man wohl von CD/DVD booten oder eine anderes Rescue System starten, jedenfalls muss man den laufenden Betrieb des Rechners unterbrechen, was auf einigen Servern wohl nicht immer geht.

Im folgenden die Möglichkeit solche überdeckte Dateien auch ohne aushängen des Filesystemes zu löschen.

verdeckte Dateien löschen ohne umount des Filesystems

Angenommen man hat ein solches Problem, dass sich unter einem gemounteten /tmp-Filesystem noch alte temporäre Dateien verstecken, die unnötigen Festplattenplatz des Rootverzeichnisses belegen. Ein umount /tmp wird im laufenden Betrieb abgewiesen, da sich unterhalb von /tmp immer geöffnete Dateien befinden. Um diese Dateien sichtbar und auch löschbar zu machen, ohne das laufende System zu beeinflussen, kann man das Rootfilesytem ein 2. Mal mounten. Die Dateien dieses Filesystems existieren danach immer noch nur ein mal. Es wird vom Linux sogar nur ein Cache für das Filesystem verwendet, aber alle Dateien dieses Filesystems sind jetzt über 2 verschiedenen Verzeichnishirarchien ansprechbar, faktisch haben wir eine doppelte Namensauflösung.

LINUX # mount | grep "/ "
/dev/sda3 on / type reiserfs (rw,acl,user_xattr)
LINUX # mount --bind / /mnt
LINUX # mount | grep "/ "
/dev/sda3 on / type reiserfs (rw,acl,user_xattr)
/ on /mnt type none (rw,bind)
LINUX # ls -il /etc/fstab /mnt/etc/fstab
450132 -rw-r--r--  1 root root 544 Oct  3 20:55 /etc/fstab
450132 -rw-r--r--  1 root root 544 Oct  3 20:55 /mnt/etc/fstab

wir sehen hier am Beispiel die Datei /etc/fstab ist jetzt auch unter dem Namen /mnt/etc/fstab zu sehen und ansprechbar.

ls /mnt/tmp/

wird jetzt all die Dateien anzeigen, die unter /tmp im Moment durch das eingehängte Filesystem verdeckt sind. Diese Dateien können jetzt auch dort gelöscht werden.

umount /mnt

hängt das doppelte Filesystem dann wieder aus.

Das verdecken von Dateien im Mountpoint bieten keinen Zugiffsschutz

Warnung: welcher Admin nun der Meinung ist, durch das verdecken von Dateien mit anderen Verzeichnissen, seien diese verdeckten Dateien auch für die User nicht mehr erreichbar, der irrt. Die Dateien lassen sich nach wie vor entsprechend ihrer Zugriffsrechte ansprechen. Man muss nur den kompletten oder relativen Path zu den unsichtbaren Dateien angeben und kann sie lesen ober beschreiben. Auch ein Ausführen ist möglich, wenn die ausführbare Datei über ihren kompletten Path angesprochen wird. Sollte es einmal vorkommen, dass eine verdeckte Datei oder ein verdecktes Verzeichnis im Path und Namen gleich der Dateien in dem verdeckenden Verzeichnis ist, ????? muss ich nochmal ausprobieren Robi 20:10, 27. Okt 2006 (CEST)

Ausnutzen dieser Technik zum Verschieben von Verzeichnissen

Als Beispiel soll hier das var-Verzeichnis, das zZ noch eine eigene Partition ist, aus Platzgründen auf das Rootverzeichnis verschoben werden. Ziel dabei ist, die Partition die im Moment noch die Dateien von /var enthält, anderweitig verwenden zu können.

Das Verzeichnis /var im laufenden Betrieb zu verschieben, geht mit Sicherheit nicht gut. Aber wenn ( /var ) eine eigene Partition ist, kann es im laufenden Betrieb nach ( / ) kopieren werden, Vorraussetzung ( / ) ist groß genug, um die Dateien von ( /var ) auch noch aufzunehmen. Dabei werden die Dateien gleich an die richtige Stelle kopiert, in das /var-Verzeichnis des Rootverzeichnis. Dort ist zu diesem Zeitpunkt allerdings noch das var-Filesystem gemountet. Dazu wird das Rootverzeichnis noch einmal zusätzlich nach /mnt gemountet und die Dateien von /var nach /mnt/var kopiert. Nach dem umount des Rootfilesystems am Mountpoint /mnt, existieren dann quasi die Dateien /var/..... 2 Mal, einmal noch auf der separaten Partition die auf /var gemountet ist, und einmal im Rootfilesystem unterhalb des Verzeichnisses /var allerdings dort im Moment verdeckt durch das andere Filesystem.

Wem das zu verwirrend erscheint, hier der Konsolauszug mit den Befehlen.

testuser@LINUX:~> su -l
Password:
LINUX:~ # cd /
LINUX:/ # mount --bind / /mnt
LINUX:/ # ls /mnt/var
.  ..
LINUX:/ # cd /var
LINUX:/var # find . | cpio -pdumC65536 /mnt/var
LINUX:/var # cd /
LINUX:/ # vi /etc/fstab    #hier Zeile /var löschen oder auskommentieren
LINUX:/ # umount /mnt
LINUX:/ # init 6

an dieser Stelle kommen wir natürlich ohne einen reboot des Systemes nicht aus.

Zur Erklärung:

1. wechseln zum User Root
2. das Rootfilesystem wird mit --bind noch ein zweites Mal temporär nach /mnt gemountet
3. ls /mnt/var das Verzeichnis ist jetzt leer und dorthin können die Dateien von /var kopiert werden
4. kopiert wird in diesem Beispiel hier mit einem cpio-Befehl
5. die /etc/fstab muss anpasst werden, also die Zeile /var auskommentiert oder gelöscht werden
6. /mnt wieder umounten
7. reboot des Systems

Nachdem der Rechner rebootet hat, ist die ehemalige Partition von /var frei für weiter Verwendung.

Robi 20:10, 27. Okt 2006 (CEST)