Suse Leap 42.3: Probleme nach Festplattentausch: Dienste nicht erreichbar

[smartysmart34]

Hallo zusammen,

eigentlich hat alles so einfach angefangen:
Mein Server läuft mit Suse 42.3. Das System ist auf einer SSD. Weil das Setup etwas älter ist und SSDs früher tendenziell nciht für Dauerschreiben gedacht waren, hatte ich SWAP, /tmp und /var auf eine klassische Festplatte ausgelagert, die ansonsten mein Fileshare beheimatet.
Die zugehörige fstab sieht so aus:


/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part5 swap swap defaults 0 0
/dev/disk/by-id/ata-Crucial_CT240M500SSD1_13400950DAAC-part1 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part6 /tmp ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part7 /var ext4 acl,user_xattr 1 2
UUID=749e1fd9-62d8-4518-bbb2-4d10b3b4a1b9 /mnt/local/fileshares ext4 defaults,user,auto 0 0


Eben diese Festplatte wurde jetzt zu klein und sollte durch eine große ersetzt werden.
Also habe ich zunächst die neue Plate zusätzlich eingebaut und partitioniert:
- swap 10GB
- tmp 30GB
- var 30GB
- Fileshare 5.3TB

Dann habe ich fileshare, var und tmp vorübergehent unter /mnt/local eingebunden, um die daten zu transferieren. Angepasste fstab:


/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part5 swap swap defaults 0 0
/dev/disk/by-id/ata-Crucial_CT240M500SSD1_13400950DAAC-part1 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part6 /tmp ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WMAZA5261137-part7 /var ext4 acl,user_xattr 1 2
UUID=749e1fd9-62d8-4518-bbb2-4d10b3b4a1b9 /mnt/local/fileshares ext4 defaults,user,auto 0 0

#/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part1 swap swap defaults 0 0
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part4 /mnt/local/fileshares_neu ext4 defaults,acl,user_xattr,user,auto,x-systemd.automount,x-systemd.device-timeout=15 0 0
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part2 /mnt/local/tmp_neu ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part3 /mnt/local/var_neu ext4 acl,user_xattr 1 2


Erste Erkenntnis:
Es ist ein Unterschied, ob ich
- in /mnt/local/var_neu stehend das Kommando "cp -p -R /var/* ." absetze oder
- in /var stehend das Kommando "cp -p -R ./* /mnt/local/var_neu".

Warum auch immer, ich habe in beiden Fällen keine Fehlermeldung bekommen, aber im ersten Fall haben Files und Unterverzeichnisse z.B. aus /var/adm gefehlt. Die waren nur beim zweiten Szenario dabei.

Hinterher die fstab auf die neue Platte umgestellt:


/dev/disk/by-id/ata-Crucial_CT240M500SSD1_13400950DAAC-part1 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part1 swap swap defaults 0 0
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part4 /mnt/local/fileshares ext4 defaults,acl,user_xattr,user,auto,x-systemd.automount,x-systemd.device-timeout=15 0 0
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part2 /tmp ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX31D87DYCV8-part3 /var ext4 acl,user_xattr 1 2


Ergebnis:
Die Maschine startet. (Gut)
Ich komme per ssh über das Netz rein (auch gut)
Wenn ich drin bin sehe ich mittels "top", dass z.B. meine Windows VM, die mittels VirtualBox beim Booten automatisch im headless modus gestartet wird, auch läuft (super)

ABER:
- Sowohl nfs-Shares als auch Samba stehen nicht zu Verfügung
- Von außen komme ich an die VM nicht ran.

In Yast2 sehe ich unter den Serverdiensten die Samba-Konfiguration und auch die NFS-Server Konfiguration. Die sehen aus wir früher. Hab sie nochmal bestätigt, keine Fehlermeldung bekommen.

Hat jemand eine Idee, woran das liegen könnte und vor allem, in welchem der vielen Logs ich ein paar konkretere Hinweise finden oder wonach ich suchen sollte?

Danke und Gruß,
Martin

[smartysmart34]

Hallo zusammen,

kurzes Update:
1) Ich habe mich tatsächlich bei den Fileshares konsistent im Pfad verklickt bzw. nicht gemerkt, dass die Ordner auf der falschen Ebene hingen. Man sollte das nicht übermüded tun. Also: Die Ordner wurden dann nach dem 4. Prüfen und Bemerken des Fehlers umkopiert -> NFS udn SAMBA gehen
2) Bei der VM hat jir Microsoft einen Streich gespielt, die haben nämlich just am Tag meines Umbaus ein Update verteilt, das RDP kaputt gemacht hat.
Nach längerem hin und her hatte ich gemerkt, dass Zugriff von einer Windows-Maschine funktioniert. Vor zwei Tagen kam der RDP-Patch, sodass auch der Zugriff von Linux auf die VM wieder läuft.

Gruß,
Martin