Zugriff auf VM NFS Share per SMB

[MarroniJohny]

Hi

Hat wahrscheinlich weniger mit vSphere als mit nas4free zu tun. Hatte schon in anderen Foren nachgefragt, bis jetzt aber leider nur eine einzige Antwort bekommen. Daher dachte ich, vielleicht kann mir ja hier jemand weiter helfen.

Ich habe bei einem ESXi 6.5 U1 einen DELL Perc H310 an eine NAS4free VM durchgereicht. An dem Adapter hängt eine 2 TB SSD, welche per NFS vSphere die VM's zur Verfügung stellt. Das klappt auch. So weit, so gut.

Nun möchte ich per SMB 3 Share über Netzlaufwerk auf die VM's zugreifen. Der Share ist eingerichtet, und der Verzeichnisinhalt wird aufgelistet. Wenn ich nun eine ausgeschaltete VM kopieren möchte, kommt die Fehlermeldung "Sie benötigen Berechtigungen zur Durchführung des Vorgangs (Unix User/root)".

Wie kriege ich jetzt lesenden Zugriff auf den Share?

Ein User im hwluxx hat dazu folgendes geschrieben:

Du musst den NFS Daemon unter einem Account laufen lassen, der unter SMB Zugriff auf das Share hat. Bei FreeNAS heist die Option Maproot b.z.w. Mapall. Wie es bei NAS4free konkret funktioniert weis ich allerdings nicht.

Leider kann ich damit nicht viel anfangen, bzw. finde so eine Einstellung bei nas4free nicht.

[~thc]

Wenn ich dich richtig verstehe, willst du eine NAS-NFS-Freigabe zusätzlich per SMB freigeben und Dateien darüber kopieren.
Das ist knifflig und von der Voreinstellung und den Fähigkeiten des NAS abhängig.

1. Ein NFS Share wird vom Client mit Dateien und Ordnern beschrieben, deren Benutzer (ID bzw. Nummer) und Rechte den NFS-Server überhaupt nicht interessieren - er muss die Benutzer selbst auch nicht kennen. Ein ESXi als NFS-Client schreibt immer als "root".

2. Beim Anlegen des NFS Shares gibt das OS des NAS eine "Standard"-Rechtemaske vor. Das kann (z.B. bei Synology) dazu führen, dass NFS-Clients nicht zugreifen können, ohne das diese Rechte per SSH angepasst werden. Es kann aber auch dazu führen, dass die Basis-Systemrechte auf dem NAS "--------+" mit erweiterten Attributen sind und der ESXi diese weiter vererbt, aber selbst als "rwxrwxrwx" wahrnimmt.

3. Eine Windows-Freigabe über den Samba-Server des NAS braucht und erzeugt einen NAS-Linux-Benutzer gleichen Namens, der dann versucht, auf diese Dateien zuzugreifen.

- Die Rechtemaske deiner ESXi-NFS-VMDK-Dateien erlaubt dem NAS-Linux-Benutzer (via Samba) keinen Zugriff
- Du kannst am NAS4free erst mal per SSH (und zur Kontrolle über SSH des ESXi !) nach den Rechten schauen

[MarroniJohny]

Hi

Hmmm. Ja Danke! Wobei ich wohl nicht ganz alles verstanden habe.

Ich habe jetzt den SMB Share in meiner Workstation nochmals neu eingehängt. Grundsätzlich geht da kopieren vom/zum Datastore, aber nicht bei allen Dateien. Auch verhält es sich nicht bei allen VM's gleich. So kann ich z.B. bei dem Beispiel unten die meisten Dateien kopieren (ausser der .vswp), bei anderen VM's kann ich nicht mal die VMDK kopieren. Ich muss dazu sagen, dass ich einen Teil der VM's erst von einem normalen ESXi Datastore per winscp kopiert hatte, und die VM's dann per SMB auf das neue ZFS Storage kopiert hatte. Ein Teil der VM's auf meinem neuen Server sind dann nachträglich hinzu gekommen.

Allzuviel basteln möchte ich auch nicht an dem NAS, da natürlich keine aktuellen Backups vorliegen. Was ja der Sinn der Sache wäre, jetzt per SMB welche anzulegen.

Die VM's waren natürlich aus für die Tests. Was vielleicht noch wichtig ist: den NFS Share habe ich unter der Version 3 in vSphere am laufen, mit v4 hatte ich den nicht zum laufen gebracht. Somit musste ich auch keinen Benutzer und Passwort beim anhängen angeben.

Beispiel 1 (hier kann ich die meisten Dateien kopieren, allerdings wurde die VM wohl per SMB zurückgespielt):

Beispiel 2 (hier geht gar nichts, die VM wurde aber per vSphere via NFS angelegt):

[~thc]

Das sieht aber ganz gut aus. Da der ESXi als root "arbeitet", interessieren ihn die Rechte nicht wirklich und dein NAS arbeitet nicht mit erweiterten Attributen.

Also einfach vom NAS oder ESXi aus in den VM-Verzeichnissen der ausgeschalteten VMs

Code: Alles auswählen

chmod go+r *

ausführen. Dann sollten alle Dateien kopierbar sein.

[MarroniJohny]

Hi

Ja, Danke!

Ich habe mir zum Test mal eine Debian VM mit 1TB thin vmdk aufgesetzt. Das Verzeichnis belegt auf der SSD 14GB.

Wenn ich die VM kopieren möchte, dann kommt wie erwartet der Fehler mit den Berechtigungen. Also VM ausgeschaltet, und

Code: Alles auswählen

chmod go+r *

eingegeben. Jetzt klappt es, nice.

Nun habe ich aber das Problem, dass obwohl die VM auf der SSD mit thin nur 16GB belegt, sich der Kopiervorgang aber trotzdem 1 TB in Anspruch nehmen will. Wie umgehe ich das, bzw. wie kopiere ich die VM so, wie sie ist?

Wär sonst nicht weiter tragisch, da sowieso die meisten VM's auf dem ESXi thick angelegt sind. Auf dem Desktop bin ich mittlerweile zu thin übergegangen, deshalb habe ich das (zum Glück) gleich mal auf dem Server getestet mit thin.

[Dayworker]

Das ganze Gehampel um SMB hättest du nicht, wenn du statt freenas/nas4free ein Solarish als OS genommen hättest. Bei Solarish ist der SMB-Server integraler Bestandteil von ZFS. Die Zugriffsrechte von NFS und SMB sind bekanntlich nicht migrierbar. Wenn du nur über ZFS sichern würdest, bräuchtest du aber überhaupt keine Verrenkung machen. Das ZFS läßt sich ja per "zfs send/receive" bitgenau sichern und etwaige Zugriffsrechte interessieren das ZFS in keinster Weise. Ich habe daher unter Nappit-AiO für den ESXi einfach ein NFS-Shares eröffnet und dem ESXi darauf Zugriff gegeben. Theoretisch könnte man auch für jede VM ihren eigenen NFS-Share anlegen und diesen dann unabhängig vom Rest per ZFS-Snapshot sichern. ZFS beherrscht auch differentielle Snapshots, damit werden nach dem "Erstsnapshot" nur noch geänderte Dateien/Ordner gesichert. Das spart viel Zeit und gegenüber einer Vollsicherung auch entsprechend viel Platz.


Die meisten Consumer-NAS bekommen, über längere Zeiträume gesehen, merkwürdige Probleme, wenn man denselben Share per NFS und SMB zugreifbar macht. Ursache dafür dürfte sein, daß sich die Zugriffsrechte nicht in Einklang bringen lassen und dann immer irgendeine Seite abstrahiert werden muß.

[MarroniJohny]

Hi

Kann ich meine bestehenden ZFS Platten mit Nappit einfach "übernehmen"? Wenn ja, ist es wohl besser, die Daten vorher zu sichern? Weil ich müsste das über Netzwerk auf meinen Desktop machen, das sichern. Und ich habe leider nicht unbeschränkt Platz (2x 6TB WD Gold, 1x am NAS4free, 1x im Desktop; bei den Platten hätte es noch ausreichend Platz). Müsste das mal ausrechnen, ob das platzmässig geht, weil um neue HDD's kaufen fehlt in absehbarer Zeit einfach das Geld. Erst brauch ich mal RAM für den Server. Und bei mir hat es eh immer 0 Platz auf den Platten und SSD, hatte erst gerade wieder eine gröbere Aufräumsaktion hinter mir.

Ist das super kompliziert, das einzurichten? Ich weiss schon, dass es von gea da nen Guide dazu gibt. Trotzdem frage ich mal in die Runde, ob das für nen noob machbar wäre

Ah ja, und viel mehr als 6 GB RAM ist im Moment nicht für den Hauptfiler. Im Frühling kann ich da dann hoffentlich gerne mehr zuweisen. Ich bin erst von FreeNAS auf NAS4free gewechselt, wegen dem RAM Problem.

[MarroniJohny]

Mmmh, ich werd dann einfach mal auf napp-it wechseln dann. Import der bestehenden ZFS Pools scheint ja kein Problem zu sein.

Habe heute mal die Software getestet, und die ist ja auch nicht gross anders, als die bereits von mir genutzten NAS Systeme. Wechsel von NAS OS mit bestehenden ZFS Pools habe ich auch schon hinter mir, das wird hier hoffentlich auch kein Problem sein.

Aber erst mal sichern die bestehenden Pools.

[Dayworker]

Solange das ZFS-Level niedriger oder gleich dem von Solarish ist bzw es keine Eigengewächse in Form von ZFS-Verschlüsselung etc gibt, sollte es beim Import keine Probleme geben. Solarish benötigt im Gegensatz zu beiden vorgenannten NAS-OS auch nicht viel Speicher, 2GB vRAM reichen da bereits zum Einstieg aus. Aber Performance ist damit natürlich nicht zu erwarten, weil mit sowenig RAM alle Daten immer von allen Datenträgern eingelesen werden müssen. Mit 4-16GB RAM wird Solarish deutlich performanter. Ich habe beispielsweise "gea" seine Nappit-AiO-Appliance mit einem 2TB-Mirror aus 2x WD-Red bei 8GB vRAM am Werkeln und bin zufrieden.

Kommt allerdings Dedup zum Einsatz, steigt der RAM-Bedarf stark an. Die Dedup-Tabellen müssen halt in den RAM passen. Da sind dann überschlagsweise mit bis zu 5GB RAM pro TB Plattenplatz zu rechnen und der RAM für den Read-Cache kommt noch obendrauf. Wobei man in meinen Augen schauen muß, ob einem Dedup abseits des eingesparten Plattenplatz überhaupt noch etwas bringt. SSDs gibt es zum entsprechenden Preispunkt auch mit 16 TB oder inzwischen mit nochmals mehr Platz.

[MarroniJohny]

Hi

Habe die wichtigen Daten, bzw. die VM's auf meinen Desktop gesichert. Dann den HBA von nas4free enfernt, und in einer neuen napp-it VM wieder hinzu gefügt.

Leider gibt napp-it auf der Konsole dauernd Fehlermeldungen aus. Importieren konnte ich die ZFS Volumes trotzdem. Was heisst das jetzt für mich konkret, bevor ich weiter mache?

[Dayworker]

Zur Fehlermeldung müßtest du mal "gea" befragen. Meine Vermutung wäre, daß das nicht relevant ist bzw nach einen Resilvering/Scrubbing auch korrigiert wurde. Richte doch mal über die Weboberfläche ein neuen Scrub-Job ein und starten diesen dann manuell. Bei SATA- teste ich alle 14 Tage und bei SAS-Platten dürfte alle 4 Wochen ausreichend sein. Was die Empfehlungen sind, hat "gea" bestimmt im Hardwareluxx-Forum bereits gepostet. Das müßtest du da mal unter ZFS-Stammtisch querlesen, ich habs vergessen.

[MarroniJohny]

Hi

Ich habe jetzt die SSD nochmals komplett gesichert, den Pool zerstört, und ein neues ZFS Volume erstellt. Dann alle VM's wieder auf die SSD kopiert. Jetzt ist der Fehler an der Konsole weg.

Leider hatte ich den NFS Server noch auf aus, als ich den Pool erstellt hatte. Wenn ich jetzt einen neuen Pool erstelle, dann kann ich unter ZFS Filesystems NFS aktivieren. Aber bei meinem bestehenden Pool ist das Feld inaktiv. (siehe Screenshots)

Wie kriege ich jetzt bei dem bestehenden Pool (EVO_2TB) NFS aktiviert?

[MarroniJohny]

Hi

Ich konnte das Dataset jetzt erstellen und habe das auch erfolgreich per NFS 3 in vSphere gemountet. Dann habe ich mit mc eine Test VM in das Verzeichnis kopiert.

Wenn ich jetzt in vSphere die VM registriere, geht das schon mal. Beim starten des Gasts kommt dann aber:

Code: Alles auswählen

 (VMDB) -45: Failed to connect to peer process.

Weisst einer gerade, an was das liegt?

[MarroniJohny]

Das scheint wohl ein Berechtigungsproblem zu sein. Wenn ich die VM's über SSH (Midnight Commander) einspiele, dann muss ich Snapshots und die vmx Datei mit chmod konfigurieren. Die wichtigsten vm's laufen wieder, allerdings hatte ich da einfach gebastelt, bis die wieder funktionierten. bzw. ich habe dann einfach die benötigten Dateien mit chmod 777 versehen.

Wie würde das von Anfang an richtig gemacht? Das einspielen der Backups via SSH?

[rprengel]

Das scheint wohl ein Berechtigungsproblem zu sein. Wenn ich die VM's über SSH (Midnight Commander) einspiele, dann muss ich Snapshots und die vmx Datei mit chmod konfigurieren. Die wichtigsten vm's laufen wieder, allerdings hatte ich da einfach gebastelt, bis die wieder funktionierten. bzw. ich habe dann einfach die benötigten Dateien mit chmod 777 versehen.

Wie würde das von Anfang an richtig gemacht? Das einspielen der Backups via SSH?

http://www.gtkdb.de/index_7_2506.html
mit welchen Rechten liegen den die Dateien auf deinem Backup-Medium?

Gruss

[Dayworker]

@MarroniJohny
Wenn ich dein PoolNFS-Bild betrachte, hast du erst die 2 Pools aktiviert. Das reicht natürlich noch nicht und da hinein würde ich auch nix kopieren. Dir fehlt halt noch das für die gewünschte Funktion angelegt Dateisystem.

Schau ich mir per WinSCP meinen ESXi an, ist der Besitzer für dessen NFS-Freigabe bzw alle Ordner und Dateien darin immer "42949672". Das bekommst du so also eher nicht nachgebildet. Am ESXi vorbei kopieren klappt, wenn man die Zugriffsmatrix auf "777" setzt und dann die VM im ESXi registriert. Dieser setzt dann seinen entsprechenden Benutzer. Diese Verfahrensweise ist auch logisch mit NFSv3, da es unter dieser Version keine Benutzer- sondern nur eine Geräteauthentifizierung gibt und daher auch jedes andere berechtigte Gerät die Daten verändert könnte, was dann mit ziemlicher Sicherheit zu Problemen unter ESXi führt. Erst mit NFSv4 wurde das geändert und eine Benutzerauth eingeführt. Wie sich dann der Zugriff verändert, entzieht sich mangels geeigneter ESXi-Version meiner Kenntnis.

[MarroniJohny]

Hi

Ich habe dann die Daten aus dem Pool wieder gelöscht, und in mein neues NFS Dataset kopiert. Auch da musste ich die Rechte dann noch per SSH setzen. Die meisten VM's laufen jetzt wieder. Gea meinte auch, dass im Falle eines Recoverys das manuelle setzen der ACL völlig normal sei, und auch keinen grossen Aufwand bedeutet.

Als nächstes wird dann ein separates managed Netz für Dienste wie vmkernel, Firewall- und Switch Zugriff sowie die NFS/SMB Geschichte anstehen. Da werde ich Euch dann sicher wieder mit Fragen löchern.

Ihr und gea aus dem luxx habt mir sehr geholfen! Gea hat das in folgendem Fred super erklärt mit den Rechten:

https://www.hardwareluxx.de/community/f ... 14985.html

ty vm @all