QNAP-NAS kann nicht gemountet werden

    Hallo.


    Ich habe meine Frage schon bei Linux-Mint-Users gestellt, und von dort hat mich ein Forist hierher verweisen.

    Da hier ja vermutlich die QNAP-Spezis lesen und schreiben, versuche ich es erneut mit meiner Frage:


    Ich habe ein QNAP-NAS (TS412), in dem vier ge-RAID-ete Festplatten stecken. Wenn ich das Gerät per iSCSI-Initiator auf einer Windows-Maschine einbinde, dann funktioniert es ganz prima. Was mich dabei jedoch schon nachdenklich stimmt, ist die Tatsache, dass mir die Windows-Datenträgerverwaltung das QNAP als Dateisystem NTFS anzeigt, denn
    ... das Gerät selbst (sein Webinterface) behauptet, dass der RAID-6-Datenträger das Dateisystem EXT4 trage...


    Nun zum Problem: Ich kann mit meinem Linux-Mint 19.1 die Verbindung zum iSCSI-Gerät herstellen (https://www.thomas-krenn.com/d…ISCSI_unter_Linux_mounten), kann das Gerät aber nicht mounten, denn in gparted steht, das Dateisystem des Geräts sei "unbekannt".


    Und das Problem scheint nicht Mint-spezifisch zu sein. Ich habe es nämlich gerade auf einem Ubuntu-Server-18.04 ausprobiert, und ich sehe die selben "Fehler": das Gerät lässt sich verbinden, nicht aber mounten, denn es hat ein "unbekanntes" Dateisystem.

    Hintergrundinfo: Bisher nutze ich einen Win-2012-R2 als Datenserver; dieser hat bei sich das Laufwerk per iSCSI eingebunden und gibt es per DFS frei.

    (Ich habe das nicht eingerichtet und erst gestern entdeckt, dass das Gerät ja eigentlich einen eigenen Fileserver mitbringt... das hat der damalige Einrichter wohl übersehen... >:( ).


    Dennoch würde ich jetzt gern - und sei es nur zu Übungszwecken - das Gerät als iSCSI-Laufwerk auf meinem Linux nicht nur sichtbar machen. sondern auch mounten und nutzen. Ich habe auch noch ein einfaches IOMEGA-"NAS", und damit funktioniert es ganz simpel. Nur das QNAP macht diese "Zicken".


    Wie gesagt:. unter Win eingebunden sieht es aus wie NTFS, das Gerät selbst meldet auf seiner Weboberfläche, es sei in Ext4 formatiert, und unter Mint eingebunden steht dort, das Dateisystem sei unbekannt. Ja, ich habe einen Dateisystemcheck auf dem Gerät laufen lassen. Seltsam, oder?

    Nochmal klargestellt: es geht nicht um "Freigaben" auf dem QNAP, sondern das Laufwerk soll "lokal" an der Linux-Maschine eingebunden sein.


    Ich suche den Fehler bei mir, kann ihn aber aktuell nicht finden. Was mache ich falsch? Danke für jeden Tipp!

    Der "Fehler" ist relativ simpel zu erklären

    Das Raid hat ein ext4 Filesystem, Du aber stellst per iSCSI eine LUN zur Verfügung, das ist nur ein Container auf dem ext4 Filesystem.

    Die LUN selbst wird aber vom zugreifenden Host verwaltet, und Windows hat sie naturgemäß mit NTFS formatiert, soweit also alles wie es sein soll.


    Und Linux erwartet natürlich ein ext2 oder ext3 als Filesystem, aber kein ntfs.

    Hast Du beim mounten mal den filesystem type ntfs als Parameter mit angegeben?


    Gruss

    Hallo.

    Zunächst lieben Dank für die schnelle Antwort! Top!


    "LUN" bedeutet, dass das QNAP für die zugreifende Maschine ein Dateisystem "emuliert"? Dann habe ich das verstanden.


    Ja, ich habe versucht, das Gerät mit Dateisystem zu mounten, das gelingt aber nicht:


    Kann oder muss ich auf dem QNAP noch etwas einstellen/aktivieren/erlauben?
    Die Sache mit der LUN (ich bin da kein Detailkenner) macht mich nun unsicher. Muss ich die erst "bereitstellen"? Für Win und Linux gar unabhängig?

    Nein, LUN bedeutet "Logical Unit Number" und emuliert gar nichts.

    Das ist einfach eine Bezeichnung einer Verwaltungseinheit.

    Ein Host "erkennt" eine LUN wie eine physikalische Festplatte, egal ob per SCSI, iSCSI oder FC angeschlossen.


    Das Dateisystem wird vom angeschlossenen Host bestimmt.


    In dem mount Befehl vermisse ich aber den Parameter -type?


    Gruss


    Edit: sorry, eben erst ganz unten gesehen das -t ntfs mit dabei ist.

    Bist Du sicher das es nur die Partition sdf3 ist?

    Hast Du es mit sdf versucht?

    Was sagte denn die Windows Datenträgerverwaltung, war die LUN dort auch in mehrere Partitionen unterteilt?

    Einmal editiert, zuletzt von FSC830 ()

    Update: Sorry für meine Unkenntnis :(

    Oder muss ich die "Parameter" der LUN auf Linux-Seite angeben, wenn ich mich verbinde? (Ich habe ganz plump den String von Thomas Krenn kopiert und angepasst.) Vielleicht nicht korrekt?

    Code
    ralfp@haelgeZimt:~$ sudo iscsiadm -m node -T iqn.2004-04.com.qnap:ts-412:iscsi.backupqnap.cf757c -p 192.168.0.7:3260 --login

Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-412:iscsi.backupqnap.cf757c, portal: 192.168.0.7,3260] (multiple)
Login to [iface: default, target: iqn.2004-04.com.qnap:ts-412:iscsi.backupqnap.cf757c, portal: 192.168.0.7,3260] successful.

    LUN: Schon klar, habe mich ungeschickt ausgedrückt. Ich meinte, das QNAP "emuliert" das Dateisystem für denjenigen, der "über die LUN zugreift".


    Aber wieso fehlt da -type?

    Ich habe alle Versionen gepostet, zunächst ohne Typ, dann mit -t ntfs und mit -t ext4. Ist das falsch?

    Hab mich doch korrigiert 8),


    Nur noch mal zur Klarstellung:

    handelt es sich um die LUN, die Du vorher an Windows hattest oder um eine neue LUN die ans Linux soll?

    Im NAS hast Du dem iscsi-Initiator des Hosts auch den Zugriff auf die LUN erlaubt?


    Ich habe hier leider nur Win und ESX die über iSCSI verbunden sind, ein Linux habe ich hier nicht zur Hand, außerdem ist das u.U. je nach Distribution leicht unterschiedlich.


    Gruss

    Zitat von FSC830

    Was sagte denn die Windows Datenträgerverwaltung, war die LUN dort auch in mehrere Partitionen unterteilt?


    Ja, das sieht dort - meiner Erinnerung nach - auch so aus. Ich binde das QNAP nochmal nach Windows ein...

    .. hmm, jetzt habe ich in meiner Unkenntnis wohl was "kaputt" gemacht:


    Auf dem Windows-Server kann ich den Datenträger nun "online" schalten, aber er steht dann dort als GPT, denke aber, dass er vorher MBR war. Außerdem steht dort zwar "Fehlerfrei (Primäre Partition)", aber das Ding taucht nicht im Explorer auf, und ich kann es auch nicht formatieren (was ich aber auch gar nicht will).
    (Habe das nun auf zwei Win-Hosts mit identischem Ergebnis probiert.)


    Auf dem Linux in gparted sehe ich drei Partitionen (LDM metadata partition 1.00 MiB, Licrosoft reserved partition 127.00 MiB & LDM 5.36 TiB). Bei allen steht "Dateisystem unbekannt".

    Zitat von FSC830

    Hab mich doch korrigiert 8) ,

    Ja, aber ich war zu schnell mit meiner Antwort ;)

    Zitat von FSC830

    Nur noch mal zur Klarstellung:

    handelt es sich um die LUN, die Du vorher an Windows hattest oder um eine neue LUN die ans Linux soll?

    Im NAS hast Du dem iscsi-Initiator des Hosts auch den Zugriff auf die LUN erlaubt?

    Ich gebe zu, mir fehlt es hier an Grundlagen (Lesetipp für mich?). Ich habe nirgendwo "eine LUN definiert", von daher ist es vermutlich die selbe wie vorher unter Windows (allerdings habe ich dort immer erst die iSCSI-Sitzung getrennt, mit anderen Worten, ich habe immer nur einen Host, der gerade zugreift).


    Wo erlaube ich im NAS den Zugriff? Unter Speichermanager - iSCSI - Erweiterte ACL gilt die "Default Policy".
    Muss bzw. kann ich den Zugriff konfigurieren? Wo denn? Ich erinnere mich, dass das von zwei verschiedenen Win-Maschinen "einfach so" ging.


    Zu meiner "Entschuldigung": jemand anders hat das Ding so konfiguriert, dass es an einer Win-Maschine hing. Das habe ich jetzt "geerbt". Und da ich von den vielen Windows-Servern wegwill, wollte ich das Laufwerk gern auf einem Linux-Server einbinden und freigeben...


    (Nebenbemerkung: ist es grundsätzlich "schlauer". das NAS selbst als Fileserver zu nutzen? Aber selbst wenn ja, würde ich mein Problem gern grundsätzlich lösen.)

    Update: Ich habe jetzt (im QNAP-Webinterface) eine weitere LUN "erstellt" und sie dem selben iSCSI-Ziel zugewiesen. Wenn ich nun das iSCSI-Ziel nach Linux einbinde, dann sehe ich es im Partitionstool gparted auch ZWEI MAL:
    Einmal wie zuvor (3 Partitionen), und das zweite Mal nur als Laufwerk ohne Partitionstabelle :-o

    Kann oder muss ich jetzt von Linux aus eine Partitionstabelle erstellen und die Partition dann "formatieren"? Oder mache ich gerade Quatsch?


    Die Hilfe auf dem NAS selbst ist da etwas wage:


    Zur Auflistung und Verwaltung aller iSCSI-Ziele und LUNs. Der Server unterstützt mehrere LUNs pro Ziel und mehrere iSCSI-Ziele. Sie können iSCSI-LUNs auf bestimmten Ziele abbilden bzw. die Abbildung aufheben.

    Nein, Du musst unter Linux eine Partition erstellen und ein Filesystem darauf schreiben, dann kannst Du die LUN nutzen.

    Wenn die LUN im Linux als /dev/sdc erkannt wird (Beispiel !), dann folgende Befehle eingeben:


    fdisk /dev/sdc - dort mit n eine neue primäre Partition anlegen (wird dann /dev/sdc1), man wird eigentlich intuitiv durchgeführt ;).


    Am Ende mit w die Partitionsdaten schreiben.


    mkfs.ext3 /dev/sdc1legt dann ein ext3 Filesystem an, das kannst Du sofort mounten und loslegen.


    Gruss

    Ich kann doch nicht zwei LUNs für den jeweils "gesamten Speicher" erstellen, oder etwa doch?


    ... ich probier das mal und berichte dann vom Ergebnis ;)

    Ok, das hat "geklappt": Neue LUN erstellt, formatiert und gemountet Allerdings "sehe" ich jetzt nicht die Daten, die vorher auf dem System sind (oder waren?).

    Oder hätte ich etwa die selbe LUN nutzen sollen, diejenige, die Unter Windows funktioniert hat und die mir jetzt in Linux ls "unbekanntes FS" angezeigt wird?


    ... ist mir jetzt auch egal, ich probiere das ebenfalls mal aus - kann ja nur mit einem Datenverlust enden... :(

    Nein, die neue LUN ist natürlich leer.


    Ich hoffe Du hast ein Backup der Daten?


    Gruss

    Nö, geht auch nicht: beide Male ist die "neu erstellte" Partition leer, und nacheinander eingebunden scheinen die beiden auch nicht deckungsgleich zu sein. (Ein Ordner angelegt, umount, dann mount der anderen LUN, nichts zu sehen.)

    Die beiden scheinen sich also den Speicherplatz zu "teilen"... obwohl jede davon die Größe 5.36 GiB anzeigt (das ist die Gesamtgröße!) - ist diese Größe nur "virtuell"?


    Außerdem zeigt mir das Partitonstool an, dass auf der NTFS-Partition 235.94 MiB benutzt seien, auf der EXT4-Partition aber 44.29 GiB benutzt seien - aber ich habe jeweils nur einen leeren Ordner angelegt :-o


    Ich befürchte, ich habe das völlig falsche Verständnis für die Konstruktion :(

    Nö... ist aber auch nicht sooo wichtig (waren nur VMs, die auch woanders gesichert wurden). Aber für die Zukunft wäre ich mir gern sicher, was da überhaupt passiert (finde allerdings nichts zum Nachlesen).


    Ich habe es jetzt so "verstanden":


    - Eine LUN ist so etwas ähnliches wie ein virtuelles Laufwerk, das Platz auf der physischen Platte bzw. RAID nutzt.

    - Verschiedene LUNS sind disjunkt (woraus dann folgt, dass die Summe ihrer Belegung nicht größer sein kann als das physische Speichermedium).

    Ist das einigermaßen korrekt beschrieben ?



    - Dass ich auf die vorher erfolgreich genutzte "WIndows-NTFS-Partition" nun nicht mehr zugreifen kann, muss Defekten im Dateisystem geschuldet sein (die vermutlich wieder mal von WIndows erzeugt wurden).

    - Aber wo liegt denn dieses Dateisystem überhaupt? Ich habe keine rechte Vorstellung, wo welche Infos einer LUN überhaupt abgelegt werden...


    Update: Ja, so scheint es zu sein, denn die gerade unter Linux erstellte NTFS-Partition kann ich nun problemlos auch unter Windows einbinden, und die EXT4-Partition sehe ich natürlich unter Windows nur als fehlerfrei (aber nicht benutzbar).


    Die originale LUN (die, die vorher meine Daten enthielt) habe ich vermutlich mit meinen Experimenten beschädigt und dann von Windows aus gelöscht. Ich nehme an, damit sind meine Daten "perdu"?

    In der Zwischenzeit habe ich mal ein wenig gesucht, es könnte auch sein das Deinem Linux noch ein package fehlt: ntfs-support.


    Zu dem Konstrukt, da müsste man mehr wissen:

    Das TS412 ist m.W. nicht ganz taufrisch, welche QTS Version läuft da drauf?

    Sicherlich keines, das schon Thin-Provisioning kann.

    Was Du da gerade machst mit mount/umount von LUNs kann ich gerade nicht nachvollziehen...:/


    Gruss

    Langer Rede kurzer Sinn für eine "Best Practice":


    - Wenn ich iSCSI nutzen will, muss ich eine LUN haben, diese "als virtuelles Laufwerk" einbinden und kann es dann wie ein lokales nutzen.


    - Der "bessere" Weg wäre aber, gleich die SMB- oder NFS-Freigabe auf dem NAS zu nutzen. Korrekt?


    Aber dann... wüsste ich gern, wie der "Dateidienst" auf dem NAS mit eventuellen LUNs zusammenpasst? Kommt das noch dazu? Gilt also, dass alle gemeinsam (Win/Mac/NFS plus LUNs) das physische Medium nutzen, dass aber die Summe ihrer Belegung maximal der Kapazität des physischen Mediums entsprechen kann? Klingt für mich logisch... aber ist es das auch?


    Um Platz-Kollisionen vorzubeugen würde ich also entsprechend

    - EINE LUN mit voller Kapazität und deaktivierte Datendienste haben

    - oder KEINE LUN und den vollen Platz über SMB-Freigabe bereitstellen

    - oder den Gesamtplatz auf LUN, SMB und NFS "aufteilen" (je nachdem, was ich dann gern realisieren möchte).


    Könnte das unterm Strich sinnvoll klingen?

    Zitat von FSC830

    In der Zwischenzeit habe ich mal ein wenig gesucht, es könnte auch sein das Deinem Linux noch ein package fehlt:

    Nö, ich denke, das kann mein Mint schon so, das "einfache" IOMEGA ließ sich ja auch einbinden. Ich nehme eher an, dass ich vorher etwas falsch gemacht habe oder das mehrfache Ein- und Ausbinden hat bei WIndows dafür gesorgt, dass das Dateisystem beschädigt wurde. Ist aber wie gesagt kein Beinbruch. Schwamm drüber (über die verlorenen Daten, meine ich).

    Zitat von FSC830

    Das TS412 ist m.W. nicht ganz taufrisch, welche QTS Version läuft da drauf?

    Sicherlich keines, das schon Thin-Provisioning kann.

    Habe gestern die Firmware aktualisiert: 4.3.3.0789 vom 02.01.2019, und "Thin Provisioning" kann ich wählen. Das ist ja wohl genau das was ich in meinen Worten als "sich den Platz teilen" beschrieben habe: Thin Provisioning

    Zitat von FSC830

    Was Du da gerade machst mit mount/umount von LUNs kann ich gerade nicht nachvollziehen... :/

    Tja... ;) ich habe die LUNs nacheinander gemountet und damit die beschriebenen Erfahrungen gemacht. Meine Beobachtungen habe ich ja gerade beschrieben und mir eine Erklärung zusammengereimt. Ist die zumindest ganz grob korrekt?

    Klares Jein...


    Es geht - abhängig von der QTS Version - beides.


    Thin-Provisioning, d.h. Du kannst LUNs und Volumes bauen die deutlich größer als die physisch vorhandene Kapazität sind, für den Hausgebrauch meiner Meinung nach nicht wirklich geeignet. Man muss dabei höllisch aufpassen das man nicht wirklich versucht den Speicherplatz zu belegen, dann passieren unschöne Dinge (filesystem full).


    Ansonsten ja, das ist die Regel, Du kannst Windows (SMB/CIFS) und Linux (nfs) Freigaben machen und/oder iSCSI benutzen.

    Natürlich muss man dann den Speicherplatz entsprechend aufteílen.

    Wobei man für SMB/nfs ein Volume benutzt und dort unterschiedliche Freigaben einrichtet (shares), diese teilen sich den Platz des Volumes.

    Man kann aber auch mehrere Volumes einrichten, dann hat man eine logische Trennung.

    Und zusätzlich wie gesagt noch iSCSI LUNs.

    Alles ist möglich :beer:


    Gruss


    Edit: Oha, das TS412 kann TP...? Hätte ich jetzt nicht gedacht.

    Ok, supi, danke, dann habe ich - mit Deiner Hilfe und meinen Experimenten - jetzt ungefähr verstanden, wie es funktioniert.


    Ja, das TS412 kann das ganz offenbar (wenn ich wüsste, ob und wie ich hier ein Bild posten kann würde ich Dir einen Screenshot schicken) - weiß nicht, ob das schon vorher ging, aber nach dem gestern durchgeführten Firmware-Update gibt es diese Option.


    Für mich noch eine "technische" Frage: Die LUN entspricht dann also dem "virtuellen Laufwerk", dort ist dann auch das Directory gespeichert? Wenn ich also eine LUN lösche (oder sonstwie ändere), dann sind die darin enthaltenen/beschriebenen Dateien verloren, denn sie liegen dann ohne Verzeichniseinträge auf der physischen Platte rum Korrekt?


    Und was die Entscheidung iSCSI vs. Freigabe angeht, ist die Freigabe der "bessere" Weg, weil ich bei iSCSI eine weitere Instanz dazwischen habe (iSCSI-"Server" plus Datenserver), während die direkte Freigabe eben nur der Server auf dem NAS ist. Auch einigermaßen richtig?


    Ich markiere dies jetzt als "gelöst". Danke an alle!

    Nochmals jein. Wenn Du die LUN löscht, sind die Daten darin auch weg.

    Damit Du eine LUN löschen kannst, musste Du sie erst deaktivieren und dann un-mappen, also keine 1-Klick-Aktion ;), man muss schon mehrmals hintereinander das richtige (falsche :S) machen...


    Der Unterschied zwischen LUN und Freigaben (Shares) ist der, das Shares ein Netzwerkbasierendes Protokoll (SMB/CIFS oder nfs) verwenden, auf eine LUN wird in der Regel über ein block-basiertes Protokoll zugegriffen (iSCSI oder FC).

    Auf ein Share greifen außerdem meist mehrere Rechner parallel zu, ohne das es zu nennenswerten Problemen kommt, eine LUN wird einem Rechner dediziert zugewiesen. Soll ein zweiter Rechner dieselbe LUN benutzen, muss das OS der Rechner damit umgehen könne, bei M$ wird das durch den Clusterdienst erreicht.

    Ansonsten stören sich die Rechner gegenseitig und es gibt wunderbare Effekte und Dateninkonsistenzen 8o.


    Außer dem wird eine LUN vom WIN-Rechner immer wie eine "echte" physikalische Platte angesprochen, ein Share nicht.


    Was nun der bessere Weg ist, das ist sehr individuell und hängt vom Einsatz ab.

    Viele Datenbanken lassen sich nicht auf einem Netzwerklaufwerk installieren sondern erwarten "lokale" Laufwerke, da bleibt dann nur iSCSI.

    Ist eine zentrale Dateiablage gewünscht, ist wahrscheinlich ein Share die bessere Wahl.


    Gruss


    P.S. Ein NAS ersetzt trotzdem kein Backup!

    Zitat von FSC830

    Nochmals jein. Wenn Du die LUN löscht, sind die Daten darin auch weg.

    Damit Du eine LUN löschen kannst, musste Du sie erst deaktivieren und dann un-mappen, also keine 1-Klick-Aktion ;) , man muss schon mehrmals hintereinander das richtige (falsche :S ) machen...

    Nochmals: danke!

    Dieses Mehrschritt-Verfahren führe ich gerade durch, aber "ulkigerweise" funktioniert das Löschen der "alten" LUN nicht - ich habe sie deaktiviert, ge-unmapped, aber das Löschen liefert einen "Unbekannter Fehler". Ich werde das Gerät mal neu starten und es dann erneut versuchen.

    Zitat von FSC830

    Der Unterschied zwischen LUN und Freigaben (Shares) ist der

    ...

    P.S. Ein NAS ersetzt trotzdem kein Backup!

    Sehr erschöpfend und einsehbar. Danke! Jetzt habe ich eine Richtschnur für die Entscheidung. (Und tatsächlich ist das so, dass der MS-DPM ein "lokales" Laufwerk braucht... aber den will ich ja auch schleunigst loswerden...)

    Kaum macht man alles richtig, schon funktioniert's...QNAP-Firmware.pngQNAP-mit-TP.png


    Update: Ich habe jetzt ganz plump das Ziel gelöscht, da war die LUN auch weg. Ist es denkbar, dass es zu jedem Ziel eine LUN geben muss, dass also die "letzte" LUN aus genau diesem Grunde nicht zu löschen war?

    Nein, ich habe meine beiden Test LUNs gelöscht und anschliessend erst das Target.


    Gruss

    Ok, dann war es bei mir etwas anderes. Aber schon seltsam, dass er dann das UNGEBUNDENE LUN mit dem Ziel zusammen gelöscht hat. Egal - "is ja noch mal jutjejange..."