Filesystem für NAS mit Zugriffen aus W10, Linux, MacOS

[sky^xs]

Moin zusammen,

nachdem ich schon seit Jahren auf meinem W2012er Server rumeiere, auf dem mehrere Linux VMs drehen und in dem auch diverse Festplatten (NTFS) hängen, ich aber immer wieder mal damit kämpfe, dass das eine oder andere Share in Linux plötzlich "verschwindet" (während die Shares von den Windows Rechnern im Netz noch problemlos erreichbar sind) denke ich darüber nach, die Platten nach und nach auf ein anderes Filesystem zu migrieren. Die Frage ist nur - auf welches?

Wie gesagt, bisher sind die Laufwerke mit NTFS und den üblichen Windowsshares unterwegs. Anbindung über SMD / CIFS. Meine Anforderungen an ein etwaiges neues Filesystem sind:
- Zugriffsrechte, die mit Windows kompatibel sind bzw. auch über Windows erstellt / angepasst werden können
- Dateigrößen >32gig aber natürlich auch kleine Dateien sollten machbar sein
- Lesender / schreibender Zugriff aus Windows (7,10, Server 2012), Linux (Ubuntu +Derivate), MacOS (10.x) sollte möglich sein
- Verzeichnisverschlüsselung oder Laufwerksverschlüsselung sollte optional möglich sein

Aktuell werden die Laufwerke als Windows Shares vom Windows Host (Server 2012) bereitgestellt. Ich könnte mir aber ebenso auch vorstellen, sie über einen Linux Server, der als VM auf dem Windows Server läuft, angeboten werden. Welches OS würde für einen Fileserver ggf. am meisten Sinn machen?

Raid oder ähnliches ist nicht geplant und es macht mir auch nichts aus, wenn die Laufwerke einzeln auftauchen und nicht als ein gigantisches Laufwerk erscheinen. Und wenn eine Platte ausfällt ist das schade, aber mehr auch nicht, es wäre nur gut, wenn dann nicht alles unbrauchbar wird - ergo kein Raid oder ähnliches.


Tja, ich bin für alles offen

 

[gea]

Das sind eigentlich drei Aspekte

1. Filesharing Protokoll
iSCSI, NFS oder SMB. Wenn man sich da unsicher ist, dann ist SMB (das Windows Filesharing Protokoll) das Richtige. Wenn Linux dann Probleme macht, muss/kann man das auf Linux lösen.

2. Dateisystem (apfs, ext4, ntfs, ZFS)
Das ist unabhängig vom Filesharing Protokoll. Lediglich bei Solarish ZFS ist NFS/SMB Sharing in das OS/ZFS integriert. Ansonst ist Sharing unabhängig vom Dateisystem

Das derzeit sicherste und leistungsfähigste Dateisystem ist ZFS. Kann man ohne Raid mit einzelnen Platten nutzen. Ich würde aber wenigstens Mirrors bevorzugen. Platten gehen doch ab und zu kaputt.

3. OS
Das ist etwas abhängig vom Dateisystem. Wenn man ZFS haben möchte ist Solarish die erste Wahl. Dafür wurde es entwickelt und da ist die Integration immer noch am Besten. Privat entweder mit Oracle Solaris (kommerziell kostet es ca 800 Euro/Jahr, der wohl schnellste ZFS Server mit den meisten Features) oder den Solaris Fork Illumos mit den Distributionen NexentaStor, OpenIndiana oder OmniOS. Für Solarish ist auch native ZFS Verschlüssellung auf Dateisysteme vorhanden. Außerdem bietet der in Solarish integrierte SMB Server die beste Unterstützung der ntfs Rechte sowie ZFS Snaps als Windows vorherige Version und den geringsten Konfigurationsaufwand - einschalten und tut.

Die Hauptalternative bei ZFS ist Free-BSD. Das ist neben Solarish eine weitere Unix Option.Für beide Varianten gibt es web-basierte Managementoptionen (NexentaStor, mein napp-it, FreeNAS, XigmaNas).

ZFS gibts auch für Linux. Ist aber vor allem interessant wenn es primär Linux sein muss. Weder vom Reifegrad noch vom Management vergleichbar zu den Unix Optionen.

 

[VirtuGuy]

Ich würde ggf mal die Ursache auf deinen Linux Maschinen suchen, es ist nicht wirklich normal wenn Mounts verloren gehen.

 

[sky^xs]

Gea...

Danke für die Auflistung. Ich werde ZFS mal ausprobieren, irgendeine alte Platte cleanen und dann mal ein paar Versuche mit Solaris in einer VM unternehmen. Das habe ich vor gefühlten 100 Jahren mal im Server Umfeld im Unix Support bedient, mit HP UX, SunOS usw.

Anyway, das war wieder ein längerer Brainfart Moment meinerseits. Ich hatte das nicht als Protokoll in Erinnerung sondern als Filesystem.
Nach deinem Post habe ich dann mal das syslog getailt und dann mal ein mount -a abgefeuert, um zu sehen, was passiert. Als Meldung kam "SMB signature verification error" hoch. Dann fiel mir ein, dass ich seit einem Passwort-Wechsel vor kurzem hin und wieder auch Probleme a) beim Logon auf der W2012 Maschine per RDP und ab und zu auch beim Zugriff auf die Fileshares von W10 aus habe. Da folgt dann die Aufforderung die Credentials einzugeben und anschließend funktioniert es da dann wieder. Das PW und Credentials sind sauber, also muss es was mit DNS oder ähnlich zu tun haben. Also einmal kurz ein nslookup auf den W2012 Server abgefeuert und eine andere IP bekommen, mit der ich erst nix anfangen konnte. Die dann aufgelöst und ??? und dann ... fiel mir der virtuelle Pihole ein, den ich seit einigen Monaten laufen habe.
Anyway, long story short. Hab den Pihole runtergefahren, die anderen VMs runtergefahren, alles neu gestartet (bis auf den Pihole) und tada, alles gut. Das grundsätzliche Problem da war, dass es zwei konkurrierende DNS Server gab (W2012 / Pihole). D.h. da wird etwas Konfigurationsaufwand nötig um beide parallel im Betrieb zu behalten. Der Windows DC wird auf den Pihole als Upstream verweisen und der Pi schiebt alles nach draußen. Optional verweist der Pihole Upstream auf den Windows DC. Anyway.. das sollte sich lösen lassen.

Davon ab hatte ich aber auch schon vor dem Pihole Probleme mit dem gelegentlichen "Verschwinden" einiger Shares unter Ubuntu und habe in der fstab auch diverse Mount Optionen ausprobiert.. u.a.

noauto,x-systemd.automount,x-systemd.device-timeout=30,_netdev

Das Problem trat aber auch damit auf. Aktuell habe ich die folgenden Mountoptionen gesetzt, die relativ gut funktionieren, aber dennoch hin und wieder das oben beschriebene Problem habe.

cifs vers=2.1, credentials=<stuff>,iocharset=utf8,uid=1000 0 0

 

[gea]

Tja, noch vor 10 Jahren war Sun die innovativste Computerfirma weltweit. Wer an der Uni/HS "bessere" Computer suchte, war schnell bei Sun. Leider haben die vor lauter Innovations das Verkaufen vergessen, wurden von Oracle gekauft und ...... naja

Gottseidank hat Sun OpenSolaris mit ZFS "rechtzeitig" als OpenSource veröffentlicht. Ansonst müssten wir alle statt der Eigentumswohnung NetApp kaufen - wenn wir "State of the Art" Storage haben wollten.

ansonst würde ich bei Linix sowas versuchen
sudo mount -t cifs -o username=User,password=**PWD**,sec=ntlmssp,vers=2. 1 //192.168.xxx.xxx/Freigabe /mnt/Freigabe/

(Linux ist halt in vielem ein Adventure Game - für jedes Problem gibt es 10 Lösungen von denen 5 funktionieren)

 

[VirtuGuy]

Mit ZFS wirst du auch nicht glücklich werden sofern du weiterhin mit "einzelnen" Platten arbeiten möchtest. Des weiteren würde bei MOunts zu einem 2012 Server gleich auf "vers=3.0" gehen, durch die wC Patche hat Microsoft so einiges geändert.

Die Meldung bezüglich Signierung ist etwas eigenartig, ein sporadisches Auftreten könnte ich mir hier tatsächlich nur durch die DNS Probleme erklären. Grundsätzlich ist es mMn nur ein Nebeneffekt, klingt für mich eher nach eine keep_alive Problem was deine Verbindung nach längerer Inaktivität einfach trennt. Welche Ubuntu Version verwendest du aktuell?

 

[gea]

Mit ZFS wirst du auch nicht glücklich werden sofern du weiterhin mit "einzelnen" Platten arbeiten möchtest.

Man hat auch mit einzelnen Platten alle ZFS Vorteile wie CopyOnWrite (kein defektes Dateisystem nach Absturz beim Schreiben), Snaps (Versionierung, Schutz vor Ransomware), doppelte Metadaten, Prüfsummen auf Daten und Metadaten, überlegene rambasierte Schreib/ Lesecaches ,...

Geht eine Platte kaputt sind die Daten wie bei jedem anderen Dateisystem ohne Raid weg. Dann braucht man halt auch mit ZFS ein Backupkonzept. Klar, ich würde immer Raid bevorzugen. Der Mehrpreis bringt mehr Performance und deutlich bessere Sicherheit der Daten. Backup braucht man aber dennoch als Disasterbackup (Brand, Diebstahl, Amokhardware). Bei versehentlichem Löschen oder Ransomware hat man ja die readonly Snaps und bei defekten Platten idealerweise ein Raid.

Was anders wäre ein reiner Mediaserver ohne aktuelle Daten und geringeren Ansprüchen an Datensicherheit. Da wäre Snapraid/Unraid eine Alternative. Das arbeitet mit raidartiger Paritydisk die "on demand" erstellt wird.Hat dann halt keine Echtzeitsicherung und man muss beim Erstellen der Paritydisk darauf hoffen, dass die Originaldaten fehlerfrei sind. Die haben dann ja keine Prüfsummen.

 

[sky^xs]

Wie gesagt, diese DNS Misere war hausgemacht. Im Nachhinein ein ganz klarer Facepalm Moment gestern, als mir der Zusammenhang auffiel. Betriebsblind nennt man das glaube ich .
Bei den Mount Optionen aus der fstab oben habe ich ja "credentials=<stuff>" stehen - da wird auf eine kleine Datei (.smbcredentials) verlinkt, die lokal liegt und in der Username und das zugehörige Password für den Zugriff stehen. Einfach um eine PW Anpassung zentral erledigen zu können.

So, nach durchführen des alltäglichen Checks fehlt mal wieder eine Platte. Die Fehlermeldung ist die altbekannte "CIFS VFS: SMB signature verification returned error = -13". Es scheint also weiterhin ein DNS Problem zu geben. Auf ein neues, nslookup auf den Server vom W10 Client aus abgefeuert:

Server: unknown
IP: 192.168.101.210 (die richtige)
Name: <servername>.domain
Addresses: 2x IP v6 gefolgt von der vergebenen IP v4.

Scheint also weiterhin eher ein DNS Problem auf dem W2012er zu sein. Reverse lookup? Damn. Gut nach Einrichten einer Reverse Lookup Zone wird der Server jetzt korrekt angezeigt.

Um auf die Fragen zu antworten:
Es handelt sich aktuell um ein 16.04 Ubuntu.
Und ja, das ist überwiegend ein Medienserver, bzw "Videorekorder". Darauf laufen u.a. noch ein Plexserver, eine zentrale MySQL DB für die diversen Kodi-Clients (vorwiegend RPIs), bei Bedarf 2 Gameserver + TS, ein (Hausnetzwerk interner) Webserver, ein Streamingserver, ein Skriptgesteuerter Video- bzw. Streamingrekorder und ein paar automatisierte Skript gesteuerte Prozessverarbeitungen, u.a. die Steuerung des Videorekorders via Email, Temperatur-Logging für ein im Aufbau befindliches Home-Automation bzw. "Smart" Home System (Eigenbau) usw..
Ja, das Ding ist meine Spielwiese für bekloppte Ideen oder "Dinge, die ich schon immer mal machen wollte" oder für Dinge, die ich im Job evtl. mal benötigen kann (bzw. das grundlegende Wissen, wie sowas funktioniert / aufgebaut ist).


Ich denke, dass ich in absehbarer Zeit beide Server (W2012 und den Haupt-Linux Server) sichern und neu (und vor allem sauber!) aufsetzen werde. Der (/die) Linux Server werde ich dann wohl mit 18.04.3 LTS aufbauen.
Speziell die Netzwerk Thematik (hallo DNS) ärgert mich gerade massiv. Offensichtlich wurde ich damals beim Aufbau von irgendwas abgelenkt und habe es nicht sauber zu Ende gebracht und eiere deswegen jetzt rum und laufe in diese Probleme. Ich war eigentlich davon ausgegangen Reverse Lookups definiert zu haben - ein Blick ins DNS zeigte, dass das nicht der Fall war .

Die Mount Optionen habe ich z.T. selbst schon in Verwendung gehabt. 3.0 vs. 2.1 z.B. hat da keinen Unterschied gemacht. Aber wie gesagt, es scheint ja letztlich am DNS zu hapern. D.h. ich kann in Kürze wieder auf 3.0 umstellen.

 

[sky^xs]

Kleines Update. Ich hab gestern cifs auf "vers=3.0" geändert und nachdem es da scheinbar auch, wie bereits zuvor erwartet und verprobt, weiterhin Schwierigkeiten gab, auf der W2012 Büchse "Secure negotiate" deaktiviert.
Das ganze erst via Powershell auf den aktuellen Status überprüft "Get-SmbClientConfiguration" und dann mit "Set-SmbClientConfiguration -EnableSecuritySignature $false" deaktiviert. Seitdem funktioniert es. Allerdings werde ich das über mehrere Tage beobachten müssen, da es in der Vergangenheit, beim erstmaligen Umstellen auf "vers=3.0" auch erst scheinbar lief und dann doch wieder umkippte. Allerdings hatte ich mir seinerzeit nicht die Mühe gemacht, die Ursache zu erforschen. Laut Microsoft ist das SMB Signature Problem evtl. mit der mangelnden oder nicht vollumfänglich ausgeführten Umsetzung der v3.0 Specs verbunden. We will see..

Info Link

/Edit
Tag 3 - läuft immer noch ohne Probleme.