Beiträge von macrobb

Hallo,
derzeit bin ich mit meinem QNAP TS419P gar nicht mehr zufrieden.
Mehrere Probleme bremsen mich aus. Habe dazu schon vieles im Forum gelesen, aber noch keine echten Lösungen gefunden.

Ein Zugriffsproblem von den iMacs (OS 10.8.5 + 10.6.8) plagt uns. Da "gönnt" sich das NAS ab und an gerne mal 30 sek. bis zu 1 min. "Bedenkpause", bevor es dann den Datenzugriff zulässt.
Anfänglich hatte ich FW 3.6 drauf, habe auf 4.1 upgedatet - hat aber keine Veränderung gebracht.

Dafür habe ich jetzt ein anderes, ganz wesentliches, neues Problem:
Das NAS habe ich täglich mit einer externen Platte (HFS+) gesichert. Über eSATA angestöpselt -> Backup -> fertig - und mit nach Hause genommen.
Aber seit 4.1 funktioniert das so nicht mehr. Die erste Sicherung läuft reibungslos durch. Aber bei der zweiten (inkrementellen) Sicherung stoppt es wegen Fehlern mit .AppleDouble, .DS..., und :2e.
Jetzt habe ich die Platte mal FAT32 formatiert. Damit bricht die Sicherung zwar nicht ab, bringt aber tausende von geskipten .AppleDouble usw.
Und was unter der alten FW noch in wenigen Minuten erledigt war, dauert jetzt Stunden.
Wenn ich diese Platte dann an den Mac hänge, sind alle Daten soweit drauf. Nur die farbigen Labes sind verschwunden - klar, sowas steht ja in den .xx-Daten.
Bei der HFS+-formatierten Platte gab's ganz wilde Meldungen, wie die Platte wäre bereits voll u.ä. Dabei haben die jetzt zu sichernden Daten ca. 450 GB - auf eine 2 TB-Platte.

Gibt's da schon Erfahrungen oder sogar Lösungen für das externe Backup?

Ich wollte mir eigentlich wegen der ganz oben beschriebenen Performance-Probleme ein schnelleres QNAP aus der TS-x53- oder TSx-69-Serie kaufen. Aber solange die Sicherung nicht funktioniert ...

Viele Grüße
Robert

Hi, ich wollte meinen Erfahrungsbericht über das Verschwinden meiner Freigabeordner hier mal einstellen. Vielleicht hilft es ja anderen Betroffenen weiter, und ausserdem bin ich immer noch auf Ursachensuche.
Zu meiner Gerätschaft: ein QNAP TS419P mit FW 3.4.xx, weiß ich nicht mehr genau. 4x 2TB-Platten, Platten 1, 2, 3 zum Raid 5 verbunden, Platte 4 ist für rsnap-Backup und nimmt stündliche Backups auf.
Täglich wird über eSATA vom Raid ein externes Backup erstellt. Als Platten kamen WD 20EADS zum Einsatz - ich weiß, die sind jetzt böse. Aber als ich das NAS gekauft und bestückt habe, waren sie noch von den Guten.
Zum Ausfalltag:
Morgens 8.00 Uhr war Platte 1 nicht mehr im Raid-Verbund. Ein Herausnehmen und wieder Einsetzen führte die Platte zurück ins Raid.
Beim Nachsehen in der QNAP-Administration zeigte das Raid keine weiteren Fehler. Dafür stand bei der SMART-Info für die Platte 4 nur noch ein "normal". Ich stieß einen Festplatten-Check an, der bekanntlich länger Zeit dauert.
Nach ein paar Stunden arbeiten meldete sich unvermittelt das Raid ab. Um 14.30 war es nicht mehr zu finden und in der Administration waren alle(!) Freigabeordner verschwunden. Im Resourcenmonitor -> Disk-Nutzung waren das Raid und die 4. Platte als komplett "leer" angezeigt.
In meiner Verzweiflung brach ich natürlich den Check der Platte 4 ab. Startete das NAS neu, spielte die aktuelle Firmware auf. Aber alles half nichts. Die Ordner blieben verschwunden.
Die Nachfrage beim Händler ergab nur (einen Tag später) den Verweis auf den QNAP-Service. Eine Anfrage dort ergab wiederum (einen Tag später) eine Antwort mit dem Hinweis "die Platten wären schuld". Es wurde eine externe Rettung versucht, die aber am Zugang scheiterte ... (das kostete mindestens nochmal 3 bis 4 Tage).

Zumindest, nach einigem Selbststudium, habe ich mir die smb.conf angesehen. Die hatte nun den Inhalt einer Webseite ... ! Da stand original HTML-Webtext drin! Und das auch noch von einer QNAP-WebSite.
Und hier beginnt die Ursachensuche, denn ich kann mir nicht erklären, wie das in die Datei kommt. Kann sowas wirklich durch die Festplatten ausgelöst werden (so der Hinweis vom QNAP-Service).
Auf jeden Fall habe ich die smb.conf von Hand neu geschrieben ... und siehe da, alle Ordner waren wieder vorhanden.

Ich konnte alle Daten nochmals sichern. Die Platten habe ich nun gegen teuere 24/7-Platten von der Kompatibilitätsliste getauscht. Nachdem alle Daten zurückgespielt waren, läuft der Server nun seit ein paar Tagen wieder.
In der Zwischenzeit konnte ich wenigsten mit meinem externen Backup arbeiten. Was aber trotzdem etwas Chaos verursachte
Ich habe nun sofort meine Backups wieder eingerichtet - was ich nur nachdrücklichst jedem empfehlen kann. Ein Raid ist kein Backup!

Kann jemand die totale Zerstörung der smb.conf nachvollziehen?

Hi, habe eine Lösung für das Problem gefunden. Im neudeutschen Forum bin ich über einen Thread gestolpert, der einen Zusammenhang mit dem Netzwerk-Papierkorb herstellt.
Daraufhin habe ich meinen Papierkorb deaktiviert ... und siehe da: Jetzt kann meine Benutzergruppe wieder Daten löschen.

Grüße
Robert

Hi, habe auf meinem QNAP 419 P die Version 3.4.0 laufen und Freigabeordner und Benutzergruppen eingerichtet.
Meine Benutzer selbst haben keine spezifischen Rechte. Sie sind gehören entsprechend einer Benutzergruppe an. Die Rechte für die Freigabeordner sind über die Benutzergruppen geregelt.
Mein Problem ist nun, dass ausser dem admin kein Benutzer Daten in den Freigabeordner löschen kann, obwohl die Benutzergruppe Lese-/Schreibrechte hat.
Solche Dinge wie "Nur der Eigentümer kann Inhalte löschen" ist nicht angewählt. Die Benutzergruppe "everyone" hat nur Leserechte. Admin hat (natürlich) auch Lese-/Schreibrechte.

Wo liegt der Fehler? So oft ich auch die Anleitung studiere oder die Online-Hilfe lese, ich komm nicht drauf. Ein Löschversuch wird immer mit der Meldung quittiert, dass ich keine Rechte zum Löschen hätte (Admin kann löschen).

Gruß
Robby

Edit: Vielleicht sollte ich interessanterweise hinzufügen, dass ich auf das NAS über ein Apple-Netzwerk zugreife. Habe in verschiedenen anderen Threads gelesen, dass sich auch Andere mit diesem Problem schon rumgeschlagen haben. Gibts da schon eine Erkenntnis? Die Berechtigungen der Benutzergruppen sind schnell erklärt: Admin hat Lese-/Schreibrechte, everyone darf nur lesen und eine Benutzergruppe (ich habe sie Workgroup getauft) hat ebenfalls Lese-/Schreibrechte.
Benutzer, die nun dieser Gruppe angehören und sich so am NAS anmelden, können lesen, schreiben ABER nicht löschen!
Eine Änderung der Gruppe "everyone" auf Lese-/Schreibrechte hat nichts gebracht. Wie oben schon bemerkt, wenn ich mich als "admin" am NAS anmelde, kann ich auch die Daten löschen.

Hi, die Antwort auf diese Frage würde mich auch interessieren.
Zwar kann ich über die Freigabeordner die Sichtbarkeit (Netzwerklaufwerk verbergen) einstellen.
Leider hat das keine Auswirkung. Meine Macs zeigen weiterhin alle Freigabeordner, ob versteckt oder nicht.

Gruß
Robby

Jaein.
Bei dem Beitrag geht es um die iSCSI-Probleme die ich mit dem NAS habe.
Aber hier wollte ich meine "Strategie" grundsätzlich überdenken, ob es nicht was Sinnvolleres, weniger Kompliziertes gibt, wie ich mit dem NAS arbeiten kann. Vielleicht denke ich einfach zu kompliziert. Wie binden andere Mac-User ihr NAS ein?
Ist die iSCSI-Variante wirklich gut oder gibts was Einfacheres?

Sorry, wollte das Forum nicht überstrapazieren oder zumüllen.
Aber das Thema beschäftigt mich jetzt schon seit fast einem halben Jahr und ich komme nicht wirklich vorwärts.
Irgendwas funktioniert immer nicht so wie es soll ...

Hi,
ich suche schon seit langem nach einer Lösung für folgende Anforderung:
Mac-Mini-Server verwaltet meine Benutzer, er ist der Open Directory-Master mit entsprechenden Benutzerordnern. Das NAS soll die Produktionsdaten beherbergen.
Wie bekomme ich es hin, dass das NAS die Benutzerverwaltung vom Mac-Server übernimmt, ich mich also nur einmal am Server (oder NAS) anmelde und Zugriff auf mein Benutzerkonto vom Server und auf die Produktionsdaten vom NAS bekomme? Kann das NAS auf die Open Direcotry-Daten vom Server zugreifen? Habe dazu nichts gefunden.
Meine bisherige Lösung war, auf dem NAS ein iSCSI-Ziel einzurichten und dieses am Server zu mounten. Damit erscheint das NAS als servereigene Platte. Eigentlich genau das was ich will. Nur macht mir das iSCSI dermaßen Probleme, dass ich kein gutes Gefühl mit den Produktionsdaten habe.
Hat jemand dazu Ideen, Vorschläge oder schon eine Lösung?

Danke, cu Robert

Hi,
nach dem Update der FM auf 3.3.3 auf meinem TS419P bricht es den Vorgang beim Anlegen eines iSCSI-LUN nach ca. einem 1 TB ab.
Danach lässt sich das NAS nicht mehr ansteuern. Weder per Q-Finder noch direkt über den Browser. Erst nach einem manuellen Neustart habe ich wieder Zugriff.
Dann sehe ich, dass von dem freien Speicher von 5,4 TB nur ca. 1 TB für das iSCSI-LUN inizialisiert wurden und hinter dem LUN-Eintrag steht "Fehler".
Mehrmalige Versuche haben immer das gleiche Ergebnis gebracht. Ist dieses Phänomen bekannt? Hat jemand eine Lösung dazu?
Bei mir werkeln 4 WD-Green-2TB-Platten, zusammengeschlossen zu einem Raid 5.

cu Robert

Hi,
ja, jetzt habe ich auch auf FM 3.3.3 upgedatet. Dafür habe ich jetzt ein ganz anderes Problem - aber der Reihe nach:
Das Unterfangen, zwei iSCSI-Ziele einzurichten habe ich aufgegeben. Kann das iSCSI-Ziel ja dann auf dem Mac partitionieren. Hat für mich den selben Effekt.
Dazu habe ich alle vier Platten zum Raid 5 zusammengeschlossen. Genau zu diesem Zeitpunkt habe ich die neue FM 3.3.3 entdeckt und geupdatet.
Nun habe ich aber das Problem, dass mir beim Einrichten des iSCSI-Ziels das NAS nach ca. 1 TB sich ins Nirvana schießt. Es hört (mehr oder weniger) auf, auf den Platten zu arbeiten und ich komme weder per Q-Finder noch direkt übers Web drauf. Es reagiert nicht mehr. Nur durch manuellen Neustart kommt das NAS wieder. Dann sehe ich, dass ca. 1 TB fürs LUN formatiert wurden. Aber hinter dem LUN steht "Fehler".
Auch weitere Versuche habe immer das gleiche Ergebnis gebracht.
Muss ich schon wieder downgraden auf 3.2.6 oder 3.2.7?
Hat jemand damit schon Erfahrungen gemacht?

cu Robert

Hi,
habe nun nach 5 Tagen Aktionismus, diversem Angstschweiß und Verzweiflung wieder auf die Firmware 3.2.7 downgegradet - und siehe da, es funktioniert wieder. Auch große Ordner oder Dateien lassen sich wieder kopieren.
Wie es aussieht haben alle Daten dieses up-and-down gut überstanden. Nur die iSCSI-Partition, die ich unter 3.3.2 zusätzlich angelegt habe, ist verschwunden?!?

Insgesamt scheint mit der FM 3.3.2 in Verbindung mit dem Mac noch was nicht so recht zu passen. Zwar fand ich in 3.3.2 ein paar gute Neuerungen, gerade bei der iSCSI-Administration, aber wenn's nicht funktioniert ...
Ist das Problem bei QNAP eigentlich bekannt und wird ein nächstes FM-Update diesen Fehler beheben?

Zwischenzeitlich wollte ich sogar die iSCSI-Geschichte ganz aufgeben, da dies immer einer unsichere Sache über Drittanbieter-Software (iSCSI-Initiator) bedeutet. Aber es ist ungemein praktisch die Benutzerverwaltung über den Mac Server zu nutzen. Nur einmal anmelden, und man hat alle zugewiesenen Ordner und Rechte zur Verfügung. Open Directory funktioniert direkt leider auch nicht, ausser man arbeitet mit diversen QPKG-PlugIns. Aber das ist mir zuviel Detailarbeit und Installationsarbeit auf Terminal-Basis. Da kenn ich mich nicht aus.

cu Robert

Hi,
habe seit gestern ein schwerwiegendes Problem mit meinem QNAP TS419P.
Beim Kopiervorgang bricht das NAS nach unbestimmter Zeit die iSCSI-Verbindung ab (mal etwas früher, mal etwas später). Das NAS selbst bleibt am Server gemountet.

Mein System:
NAS hängt an MacMini mit 10.6.4 Server
Anbindung per iSCSI (globalSAN)
QNAP Firmware 3.3.2 (0819T) (gestern aktualisiert)

Zuvor hat diese Verbindung fehlerfrei funktioniert. Erst nach der Firmware-Aktualisierung tauchte der Fehler auf. Zuvor war die Version 3.2.7 drauf.
Der Hintergrund für die Aktualisierung war, dass ich mit der Vorversion mein TM-Backup nicht zu laufen bekommen habe.
Es sind drei Platten zum Raid 5 zusammengefasst. Die vierte sollte als TM-Backup-Platte fungieren.
Leider hat TM aber diese Platte nie hernehmen wollen und das Backup immer nach ca. 200 MB abgebrochen.
Das Raid 5 hat super funktioniert.

Beim Abmelden des NAS zeigt das globalSAN "Disconnected" (logisch). Teilweise zieht der Ausfall im MacMiniServer einen Fehler des AFP-Dienstes nach sich. Der Dienst stoppt und bringt einen Fehler. (Wahrscheinlich eine Reaktion auf das ausgefallene NAS?).
Hängt das NAS am Server und es wird nichts kopiert tritt kein Fehler auf, also in dem Sinne, dass es sich nach einiger Zeit selbst abmelden würde.

Kennt jemand den Fehler oder hat eine Lösung dafür?

Ach ja, die Warnmeldung wegen des UDP Port 1900 bekomme ich auch alle 10 Minuten auf mein E-Mail Aber das ist, denke ich, eine andere Geschichte.

Danke, Robert