Beiträge von rainer.100

Danke, genau das meine ich mit "komplex", die Liste von Geri_ch.

OK, danke. Das habe ich mir schon gedacht. Ich hatte gehofft, dass jemand weiß, ob man IP-Adressbereiche der aus China stammenden Providern sperren kann, aber das schein komplex zu sein.

Ich schalte einfach die myQNAPcloud wieder aus, dann sind die Chinesen erstmal wieder außen vor. Ich experimentiere gerade damit, die WEB-Zugriffe auf die benötigten Dienste in meinem LAN über DDNS, Subdomains und entsprechenden Weiterleitungen auf die jeweiligen Ports zu realisieren. Das scheint ganz gut zu funktionieren. Nebenbei habe ich auch den Effekt, dass nicht noch ein dritter Server (der myQNAPcloud-Dienst) für die Umleitung auf das NAS auf dem Weg liegt.

Seit sieben Jahre oder gar länger hänge ich mit QNAP-NAS im Netz. Die NAS sind aus dem WEB über DDNS und seit rund zwei Jahren sogar über meine eigene Domain erreichbar, per SSL und über VPN (des Routers). In dieser Zeit gab es nie IP-Angriffe aus dem Internet auf meine Geräte. Gestern ich habe mich bei myQNAPcloud angemeldet und schon geht es los. Hier ein Beispiel:

Date/Time: 2014/10/24 19:46:17
Level:  Warning
[Security] Add IP: [218.249.94.2] to ban list for 30 minutes.

Es sind IP-Adressen aus China.

Hat das was mit myQNAPcloud zu tun, als legale Zugriffe für diesen Dienst, oder sind das illegale Angriffe, weil ich seit der Anmeldung bei myQNAPcloud nun bekannt bin wie ein bunter Hund?

Kann ein Angreifer auf diese Weise in meinen NAS trotz SSL hacken? Ich gehe davon aus, das meine Kommunikation mit oder über myQNAPcloud durchgehend verschlüsselt ist. Brute force etc. sollte ja nicht funktionieren, wenn ein Angreifer alle fünft Versuche auf die Ban-List landet.

Ich habe die Vermutung, dass Hacker einfach alle Adressen xxx.myqnapcloud.com durchgehen und schauen ob irgendjemand davon antwortet.

Wie kann ich denn bei den Sicherheitseinstellungen im NAS den Adressbereich aller chinesischen IP-Adressen blocken? Werden bei geblockten IP-Adressen trotzdem Warnungen ins Logbuch geschrieben oder hätte ich dann Ruhe?

Für Eure Hilfe schon mal ein herzliches Dankeschön.

seit einigen Tagen werden auf dem ts559 pro II abgelegte Bilder (jpg) sowohl in der Vorschau als auch im Vollbild mit bunten Streifen, teilweise oder auch komplett einfarbig grau dargestellt. Aber nur wenn ich die Bilder mit der "File Station" aus der GUI des qnap oder mit der app qfile vom iPhone oder vom iPad abrufe. Mit anderen Apps oder mit sämtlichen anderen PC-Programmen werden die Bilder normal dargestellt.
Das betrifft nur neu auf den qnap gespeicherte Bilder. Die vorher vorhandenen Bilder werden korrekt dargestellt.

Folgendes ist in den letzten Tagen durchgeführt worden:
Eine 3G HDD im RAID5 ist ausgefallen und wurde ausgetauscht.
Die Firmware des 559 ist v 4.1 vom 12.06.2014. Die File Station und qfile sind die aktuellsten Versionen.

Ich gebe folgendes auch mal an, obwohl man das als Fehlerquelle fast ausschließen kann, da die Bilder ja nur mit der qnap-eigenen Software nicht richtig angezeigt werden.
Die Bilder werden vom PC mit Adobe Lightroom im RAW-Format bearbeitet und als JPG auf den qnap exportiert. Vor kurzem wurde der PC komplett neu aufgesetzt und eine neue Lightroom-Version aufgespielt. Die letzten funktionsfähigen Bilder wurden vor den ganzen Maßnahmen exportiert, die fehlerhaften Bilder wurden alle nach all den Maßnahmen erstellt.

Wie oben erwähnt, ich tippe auf die neuen Versionen von qfile und File Station. Dagegen spricht allerdings, dass die bisherigen Bilder korrekt angezeigt werden. Hat jemand eine Idee?

Bei der App QFILE bekomme ich neuerdings den Fehler "File Station ist noch nicht aktiviert. Kontaktieren Sie bitte Ihren Administrator". Die Meldung kann mit dem Button "Ablehnen" bestätigt werden.
Der Fehler tritt auf, wenn ich mich via IPhone mit dem QNAP 559 PRO II (FW 4.01 oder auch 4.02) verbinden möchte - egal ob local oder per ssl via Internet.
Sämtliche benötigten QNAP-Dienste für die App sind aktiviert - auch die File Station.
Der Zugriff funktionierte bisher einwandfrei. Ich vermute, dass der Fehler nach dem letzten Update der App (v 1.3.0808) auftritt.
Wer kann helfen?

Ich habe einen neuen Surround-Receiver Onkyo TX626. Dieser verfügt über einen Netzwerkanschluss und DLNA-Fähigkeit.
So bald der Receiver in mein Netzwerk integriert wird - via DHCP oder über manuelle IP-Adressvergabe - bekomme ich von meinem QNAP 559 PRO II mit Firmware v4.01 laufend Access Violations auf Port 9000. Schalte ich am QNAP den Mediaserver aus, bekomme ich Access Violations auf die Ports TCP 139 und 445. Die Adresse des Qnkyos kommt für 30 Minuten auf die Ban-List. Die Systemwarnungen kommen aber alle paar Minuten weiter.

Am Onkyo kann man keine Zugriffsdaten (Nutzer, Kennwort) hinterlegen.

Hat jemand eine Lösung wie der Receiver seine Netzwerkfähigkeit nutzen kann, ohne dass mein Mail-Accound bzw. die Systemprotokolle mit Qnap-Warnings volllaufen?

Das Netz wird mit einer FritzBox 7570 betrieben.

Danke Helmut, das hatte ich schon alles versucht - Eigenschaften/Sicherheit, Eigenschaften/Freigabe, Besitz übernehmen als Administrator, Administratoren etc. - alles ohne Erfolg. Es blieb die Vermutung, dass irgendetwas mit der Verwaltung des LUN auf dem Qnap passiert sein könnte.

Nach Deinem Hinweis, der eigentlich logisch ist, habe ich nochmals alles durchgespielt und es nach vielen Versuchen geschafft.
Der Server 2012 unterscheidet irgendwie zwischen dem User Administrator, der Gruppe Administratoren, den "normalen" Benutzern und einem bei der Installation explizit anzugebenen Admin. Nur(!) mit letzterem konnte ich den Besitz des Laufwerkes übernehmen.

Ich habe einen 559 mit FW 3.8.0.
Darauf sind zwei iSCSI-Ziele eingerichtet. Jeweils mit einem LUN. 1,5TB und 1TB.
Die Ziele waren bisher auf einem Windows Home Server 2011 jeweils als ein Laufwerk eingebunden - ohne Chap.
Nun habe ich einen Windows Server 2012 und wollte die Ziele wieder einbinden. Der iSCSI-Initiator scheint identisch mit dem des WHS 2011 zu sein. Nach Eingabe der IP des Qnap wurden beide Ziele angezeigt, in Windows eingebunden und mit einen Laufwerksbuchstaben versehen. Auf das 1TB-Ziel kann ich Zugreifen und sehe alle "alten" Daten. Beim Zugriff auf das Laufwerk des 1,5TB-Ziels kommt der Fehler
"Der Pfad ist nicht verfügbar. Auf S:\ kann nicht zugegriffen werden. Zugriff verweigert." Im Qnap wird die Verbindung des Windows Servers angezeigt.

Das gleiche Problem tritt auch auf, wenn ich besagtes Ziel auf einem der Windows Client-PC einbinden möchte.

Was mache ich falsch?

Zum Abschluss
Die STxxxxDM001 stehen seit einiger Zeit wieder auf der Kompatibilitätsliste.
Ab der Firmware 3.7.1 funktionieren die Platten perfekt, ab 3.7.2 sind auch mögliche Standbyprobleme behoben.

Mit Erschrecken stelle ich fest, dass die Systemprotokolle bei meinem 559 Pro II nicht mehr aufgezeichnet werden. Früher wurde jedes Login und jeder Zugriff aufgezeichnet. Nun ist die Liste Leer.
Irgend wie sieht das bei der Firmware 7.1 auch anders aus. Auch nach dem heutigen Update auf 7.2 bleibt die Liste leer.

Bei Verbindungstyp sind alle (!) Einträge aktiviert.
"Alle Ereignisse" ist ebenfalls eingestellt.

Wenn ich auf "Protokollierung starten" klicke, spingt die Anzeige auf "Protokolierung stoppen" und nach ein paar Sekunden wieder auf "Protokollierung starten".

Die Systemprotokolle und Online-Benutzer werden angezeigt.

Wer kann helfen?

Auf meinem TS 559 Pro II ist die Firmware 3.7.0 installiert. Auf die Foto Station habe ich Zugriff und kann mich mit den Admin-Zugangsdaten des NAS dort anmelden und alle Funktionen nutzen.
Beim "Konto Hinzufügen" erhalte ich beim Speichern das PoPup "Error" mit dem Text "Fehler".
Das gleiche Problem tritt auch bei der Music Station auf.
Hat jemand eine Idee?

Inzwischen hat auch der sehr freundliche Supportmitarbeiter auf die letzten Screenshots und meiner 18 Punkteliste geantwortet und tippt auf Fehler im DOM oder am Mainboard und bot eine Reparatur an.

Zuvor habe den Rat von GorillaBD berücksichtig. Dieses mal habe ich nur eine Platte eingebaut. Den MBR und die Partitionen der Platte habe ich zuvor wieder gelöscht. Das System habe ich über den Finder neu Konfiguriert mit Single Disk. Dies dauerte eine Weile ist aber deutlich schneller als das Raid5 zu synchronisieren.
Das Systemlog zeigte an, dass die Platte erfolgreich initialisiert und formatiert sei.
Dann der Test:
Der erste Neustart lief durch. Keine Auffälligkeiten im Bootbildschirm.
Der zweite Neustart blieb wieder hängen und zwar bei x86_64_start_kernel.

Hier der Syslog des heutigen Tests:
Zwischen 20:10 und 20:32 liegt der gescheiterte Bootvorgang.
Danach habe ich das NAS ausgeschaltet, Stecker gezogen und neu gebootet. Diesesmal hat er durchgebootet.
Es scheint tatsächlich der Flash defekt zu sein.

2012-05-15 15 20:34:07 System 127.0.0.1 localhost Re-launch process [smbd].
2012-05-15 14 20:34:07 System 127.0.0.1 localhost Re-launch process [nmbd].
2012-05-15 13 20:32:33 System 127.0.0.1 localhost The second boot area on the flash is corrupted.
2012-05-15 12 20:32:26 System 127.0.0.1 localhost The first boot area on the flash is corrupted.
2012-05-1511 20:32:19 System 127.0.0.1 localhost System started.
2012-05-15 10 20:10:21 System 127.0.0.1 localhost System was shut down on Tue May 15 20:10:21 BST 2012.
2012-05-15 9 20:09:13 admin 192.168.178.10 --- [Power Management] System will be restart now.
2012-05-15 8 20:03:47 System 127.0.0.1 localhost System started.
2012-05-15 7 20:01:50 System 127.0.0.1 localhost System was shut down on Tue May 15 20:01:50 BST 2012.
2012-05-15 6 20:00:41 admin 192.168.178.10 --- [Power Management] System will be restart now.
2012-05-15 5 20:29:21 System 127.0.0.1 localhost [Single Disk Volume: Drive 1] Initialization completed.
2012-05-15 4 20:29:16 System 127.0.0.1 localhost [Single Disk Volume: Drive 1] Formatting completed.
2012-05-15 3 20:25:25 System 127.0.0.1 localhost [Single Disk Volume: Drive 1] Start formatting.
2012-05-15 2 20:23:58 System 127.0.0.1 localhost [Single Disk Volume: Drive 1] Start initialization.
2012-05-15 1 20:13:24 System 127.0.0.1 localhost System started.

Das Gerät geht dann ersteinmal auf die Reise in die Niederlande :cry:

Ich glaube das System hat einen Schaden, oder hat noch jemand eine Idee?

Hier meine Vorgehensweise gemäß Euren bisherigen Tips:

1. Die Seagateplatten Low-Level formatiert
2. Die Platten mit SeaTools auf Fehler geprüft
3. Das NAS gemäß der Anleitung http://download.qnap.com/Storage/Techni ... de_DEU.zip Punkt 9 komplett neu geflasht (Firmware V 1.0.9). Die Anleitung wurde auf den Punkt genau befolgt
4. Keine (!) Platten eingesteckt
5. Mit dem Finder die Firmware 3.4.1 (viewtopic.php?f=348&t=16499) aufgespielt. System neu gebootet
6. Eine Platte eingeschoben
7. Über den Finder die Configurationsassisten mit Platteninitialisierung gestartet. Dieser lief nun endlich ohne Fehler durch. Allerdings war die Platte auf der Website (siehe Pkt. 10) trotzdem nicht initialisiert
8. System neu gebootet
9. Über die Webadministration die aktuelle Firmware 3.6.1 aufgespielt
10. System neu gebootet
11. Zwei weitere Platten eingeschoben
12. Raid5 aufgebaut und initialisiert. Der Raidverbund wurde vollständig initialisiert (ca. 5 Minuten)
13. System neu gebootet – funktionierte
14. Zur Sicherheit habe ich das System erneut neu gebootet, da ist der Fehler wieder. Im Display steht mal wieder „System Rebooting, Please wait …“ Auf dem Bildschirm bleibt das System wie im Bild zu sehen hängen.
15. System ausgeschaltet, Stecker gezogen, System neu gestartet. Am Bildschirm ist zu erkennen, dass er Probleme mit der Partitionstabelle hat und ein Rebuild durchgeführt werde (10%, 20% etc.). Dies dauert ein paar Sekunden und der Bootvorgang wird abgeschlossen.
16. Im Systemprotokoll wird nun angezeigt [RAID5 Disk Volume: Drive 1 2 3] Start resyncing. Nach gut 10 Stunden war das Raid synchronisiert
17. Neustart des Systems – System bleibt beim booten hängen
18. Bei weiteren Neustartversuchen wieder einmal erschien auch wieder die Rebuild-Meldung

Ich habe das auch an QNAP geschickt.

Das Recover gemäß Anleitung hat funktioniert. Es ist nun die Testfirmware 1.0.9 drauf. Gemäß Anleitung habe ich nun versucht (ohne die Platten einzuschieben) das Update auf 3.6.1 mit dem Finder durchzuführen. Dieser bricht wegen angeblicher Netwerkprobleme ab, ich soll die Webadminseite zum FW-Update verwenden. Diese startet aber automatisch die Quick Configuration. Diese will aber, dass man eine Platte einschiebt, welche aber gemäß Recover-Anleitung erst nach dem Update eingesteckt werden soll.
Schiebe ich die Platte rein und lasse diese initialisieren, bleibt die Initialisierung der Platte in der Quick Configuration stehen bei 20% stehen.
Sage ich bei der Quick Configuration er soll keine Platte initialisieren, komme ich auf die Admin Seite und kann dort ein FW-Update starten. Dieses bricht aber ab (Failed).
Initialisiere ich die Platte und mache dann dass FS-Update, bricht das Update auch ab.

Jetzt bin ich mit meinem Latein am Ende.

Hallo GorillaBD,

klar, das 559 ist ein X86. Ich habe nur die Beiträge die in Deinem Link unter Punk 8 stehen gelesen und da gab es nur die Links auf das Image bis zum 419.
Ich werde den Punkt 9 durcharbeiten und hoffe, ich komme damit klar.
Geradae habe ich auch ein altes Firmwareimage 3.6.0 gefunden. Dies werde ich zuerst testen.

Herlichen Dank, wenn ich nicht weiterkommen, melde ich mich hier wieder

Ich habe Probleme mit meinem 559. Das System bleibt beim booten oder beim rebooten häufig hängen und dies an unterschiedlichen Stellen. Neuerdings ist der letzte Eintrag der beim Bootvorgang auf dem Monitor steht "... x86_64_start_kernel ..."

Die ursprüngliche Ursache ist die von QNAP eingeräumte Inkompatibilit der Seagateplatten STxxxxDM001. Diese Platten sind auch seit ein paar Tagen aus der Kompatibilitätsliste gestrichen "Not recommended". QNAP arbeitet an der Behebung des Fehlers und soll mit nachfolgender Firmware (bei mir derzeit 3.6.1) behoben sein.

QNAP empfohl mir die Platten low-level zu formatieren (dies behebt laut Qnap besagte Inkompatibilität) und auf Fehler zu prüfen sowie die aktulle Firmware erneut aufzuspielen. Dies habe ich getan.
Inzwischen ist das ganze System mit den Bordmitteln auf die Werkseinstellung zurück gesetzt.
Ich habe das System mit einer Singeldisk neu aufgesetzt. Die Disk wird allerdings vom Assitenten nicht von alleine initialisiert, dies musste ich nachträglich von Hand ausführen. Auch eine älter Platte anderen Types mag er nicht.

Ich bekommen das NAS zwar ans laufen, aber spätestens nach einem Reboot bleibt es wieder hängen.

Ich habe hier an verschiedenen Stellen gelesen, dass diverse QNAP-NAS (bis zur 419) mit einem Reburn-Image in den tatsächlichen Urzustand gebracht werden können. Gibt es diese Möglichkeit auch für das 559 (x59) PRO II? Wenn ja, wo finde ich das Image.
Hat noch jemand einen Link auf die Firmware 3.6.0? Diese würde ich ggf. auch noch mal testen wollen.

Ich würde mich freuen mit Eurer Unterstützung das System noch dieses Wochenende zum fehlerfreien Laufen zu bekommen. Ansonsten werde ich mich am Monatag wieder an den Support wenden, was den Ausfall natürlich um einige Tage verlängern wird.

Hallo, dann schaut mal meinen Eintrag hier an: http://forum.qnapclub.de/viewt…&t=20480&p=117758#p117758

Qnap spricht von möglichen Problemen mit den ST2000DM001 (ist wohl baugleich mit der ST3000DM001) und verpricht Besserung mit neuer Firmware.
Das mit den lauten und häufigen Parkgeräuschen ist nicht von der Hand zu weisen, ich habe vier ST3000DM001 aus zwei verschiedene Baureihen, alle vier sind lauter als dass, was ich bisher an Platten hatte.

Ich habe die Platten gekauf, da standen diese in der Komptibilitätsliste ganz oben. Siehe da, seit zwei Tagen stehen die Platten unter Not Recommended Hard Drive
Ich hoffe Qnap bekommt das mit der versprochenen Firmware auch wirklich hin.

Also, bei mir läuft ein Raid5 auf einem TS 559 Pro II mit drei von den DM001. Auch bei mir machen die Platten spordaisch ein quitschendes Geräusch (alle drei Platten kurz hintereinander). Dies dürfte tatsächlich auf das Parken zurückzuführen sein, dann macht die Seagate dies aber ziemlich oft !?! Die DM001 sind die ersten Platten die ich kennen, die beim Parken so einen Krach machen.

Zur Kompatibilität:
Qnap räumt bei der ST2000DM001(die ST3000DM001 dürften baugleich sein) Probleme ein, die derzeit analysiert und ggf. mit der kommenden Qnap-Firmware behoben werden. Demnach werden die Platten oftmals vom NAS ausgeworfen, was auch mir schon einmal passiert ist. Bei mir tritt neuerdings der Fehler auf, dass das NAS beim Booten hängen bleibt. Seit dem haben einige wenig der Daten eins Splien - seltsames verhalten bei den Userberechtigungen, die lassen sich nicht mal mehr löschen.
Qnap empfiehlt die Platten und den MBR mit einer Low-Level-Formatierung zu überscheiben. Dies solltet Ihr aber nur machen, wenn bei Euch auch solche Fehler auftreten. Wartet an sonsten lieber auf die neue Firmware - never touch a running HDD
Ps.: Ein Backup solltet ihr aber schon im Petto haben.
Ich habe nun eine vierte ST3000DM001 eingebaut, um die Datenstruktur vom Raid auf diese zu kopieren. Gerade formatiere ich die drei Platten aus dem Raid - das kann dauern
Danach werde ich den Raid5 und das System komplett neu einrichten und die Daten von der Original Quelle (dieses NAS ist nur ein Spiegel) "restaurieren".

Ich hoffe, dass dieser Akt und/oder die neue Firmware mein System wieder fehlerfrei ans Laufen bringen.
Zum Vergleich: Mein alter TS109 Pro läuft schon seit Jahren im Dauerbetrieb mit einer 1,5TB, ebenfalls von Seagate, und läuft und läuft und läuft ...

Nachtrag: seit zwei Tagen stehen die STxxxxDM001 unter Not Recommended Hard Drive

Auch ich habe ein iSCSI mit Thin Provisioning von 1500 GB. Ein Windowssystem ist mit dem LUN verbunden und belegt davon rund 733 GB.
Im Ressourcenmonitor wird direkt unter dem Raid-Verbund die Gesamtkapazität, die verwendete Kapazität und die noch freie Kapazität angezeigt. Die 733GB des iSCSI-Lun werden hier korrekt berücksichtigt.
Datenträger: RAID 5-Datenträger: Laufwerk 1 2 3
Gesamt: 5542.04 GB
Verwendete Größe: 1079.74 GB
Verfügbarer Speicherplatz: 4462.30 GB

In dem darunter abgebildeten Chart wir die Kapazität des LUN definitiv nicht angezeigt. Die in der Legende zum Chart angezeigte freie Kapazität entspricht zwar der oben aufgeführten freien Kapazität, addiere ich die in der Legende angezeigten Werte dazu, fehlen genau die rund 733GB des LUN.

Das dürfte wohl ein Bug sein. Bei mir ist dir Firmware v3.6.1 installiert.

Es wäre schön, wenn iSCSI-LUN im Chart und der Legende mit aufgenommen würden - bitte einzeln bei mehreren LUN.

Danke, ich hatte nur die 35W bzw. das 1W im Kopf.
"Sleep mode: 19W, In Operation: 35W, Power-off (in WOL mode): 1W"

Ich werde mal mit einem automatisierten WOL experimentieren. Es gibt ja zahlreiche WOL-Tools. Vielleicht kann man das ein oder andere dazu bewegen als Dienst vor der eigentlichen Benutzeranmeldung zu agieren, um dem NAS einen kleinen Vorsprung beim Starten zu gewähren.