Ich bin immer wieder fasziniert von den Beschreibungen behobener Fehler in den Releasenote-Einträgen. behobenen Wenn ich ein Verhalten wie
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
- Fixed an issue where a user account with multibyte characters in their username could not set port trunking in Network & Virtual Switch.
absichtlich so programmieren wollte - ich wüsste nicht, wie ich das anstellen sollte. 
Mod: Unnötiges Volltextzitat gekürzt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Verstehe ich nicht... Sollten nicht gerade die sowas lesen?
Die Kausalität verläuft umgekehrt: weil die sowas nicht lesen, machen sie ihr NAS vom Internet aus erreichbar.
Mein Problem, dass per "Schedule: Auto-Backup" gestartete Jobs sofort ohne Endemeldung abbrachen, tritt mit der Version 24.1.0515 ebenfalls nicht mehr auf.
Außerdem scheint das Uraltproblem, dass Jobs nach dem Start bei 5% Fortschritt stehen blieben, vorsichtig ausgedrückt, deutlich seltener aufzutreten.
Will sagen: seit dem Update ist es noch nicht wieder vorgekommen.
Bei meiner TS-451D2 sind das rund 90-120MB/s.
Die dürfte man auch unter USB 2 erreichen.
Kaum. USB 2.0 hat 480 Mbit/s brutto, und ein bisschen Overhead geht auch noch runter. Mehr als 50 MB/s sind da nicht drin.
Deine IPv6-Adresse sollte schon eine öffentliche sein. Private Adressen mit CGNAT gibt's meines Wissens nur bei IPv4.
Der QNAP-Update-Prozess: "vor dem Update einmal manuell neustarten, eine halbe Stunde warten, Update durchführen inklusive abschließendem Neustart, zwei Stunden danach schauen ob alles ok ist, sonst nochmal manuell neustarten" ist für ein Heimgerät ja ok, wenn auch lästig.
Für einen professionellen RZ-Betrieb ist das eher uncool.
Da wünscht man sich doch einen definierten und planbaren Update-Prozess mit möglichst kurzer und vor allem kalkulierbarer Downtime.
In meinen Augen sieht die in Beitrag #1 gezeigte Speicherauslastung völlig normal aus.
8 GB sind von qemu-system-x86 belegt, also der Windows-VM, das ist schlicht das dieser VM zugewiesene RAM.
Vom Rest sind über 1 GB frei.
Wo ist das Problem?
Nächster Schritt soll jetzt eine Teamviewer-Sitzung sein, um diesen Fall live zu testen.
Update 3: Der vereinbarte Teamviewer-Termin kam, der vereinbarte Teamviewer-Termin ging, nichts ist passiert. Keine Teamviewer-Verbindung, keine Absage, keine Mitteilung, keine Antwort auf meinen Chat Request, nur Schweigen im Walde. Existiert die Firma QNAP noch? Wurde die Service-Abteilung aus Kosteneinsparungsgründen geschlossen? Man weiß es nicht.
Ja, ja. So ein Neustart kann Wunder bewirken. Das wusste man schon zu Urzeiten, als die Menschheit noch mit MS-DOS unterwegs war.
Urzeiten? MS-DOS? Das kam doch erst so vor vierzig Jahren?
Davor gab es CP/M-80, Unix System III, VAX/VMS, DEC RSX-11M, IBM OS/360. CDC NOS/BE, und das Betriebssystem der TR-440 mit den deutschen Befehlen.
(Wie immer das nochmal hieß - fällt mir gerade nicht mehr ein, obwohl es doch erst 50 Jahre her ist ...)
SCNR
Kann ich mir nicht vorstellen. PCI ist dann doch von der Technologie her ziemlich anders als USB. Aber - Versuch macht kluch!
#!/bin/sh
# reattach ejected external disk
#
# TS-228A Front USB:
#USBDEVICE="2-1"
# TS-233 Front USB:
USBDEVICE="6-1"
echo 0 > /sys/bus/usb/devices/$USBDEVICE/authorized
usleep 100000
echo 1 > /sys/bus/usb/devices/$USBDEVICE/authorizedFür andere Modelle und Anschlüsse muss man halt einmal im syslog schauen, unter welcher USB-Devicenummer die auftauchen.
Update 2: Der Support hat sich wieder gemeldet. Wie vermutet sollte ich die Version 24.0.0304 wieder installieren, die Option "Eject after completion" im Job deaktivieren, die USB-Platte anschließen und den Remote Support nochmal aktivieren. Kurz vor Ablauf der Remote-Support-Freigabe wurde dann der Job zweimal gestartet und lief fehlerfrei durch. Der Support äußerte darauf die Vermutung, der Absturz trete nur beim automatischen Start des Jobs durch Anschluss der Platte ("Schedule: Auto-Backup") auf. Das konnte ich durch eigene Tests bestätigen.
Nächster Schritt soll jetzt eine Teamviewer-Sitzung sein, um diesen Fall live zu testen. (Die Möglichkeit, die USB-Verbindung per Kommandozeile zu trennen und wieder herzustellen, kennt der QNAP-Support wohl nicht.) Die Irrungen und Wirrungen der Terminfindung erspare ich euch. Heute in einer Woche soll die Party steigen, wenn nichts dazwischen kommt.
derkolarsky zu den Antwortzeiten: Bei mir dauert es bei einfachen Rückfragen grundsätzlich zwei Tage, bis eine Antwort kommt, bei komplexeren Rückfragen auch länger. Falls man innerhalb dieser Frist irgendetwas nachfragt, beginnt sie von vorn zu laufen. Wenn Remote-Zugriff angefordert wird, dauert es 5-6 Tage ab der Aktivierungsmeldung, bis tatsächlich zugegriffen wird. Immer wieder kommt es aber auch vor dass die erste Aktivierung nach 7 Tagen ungenutzt ausläuft und irgendwann eine Bitte um erneute Aktivierung kommt. Dahinter steckt meinem Eindruck nach keine Absicht, sondern es spiegelt schlicht die Personalausstattung des QNAP-Supports im Verhältnis zum Fallaufkommen wieder.
Update: Der Support hat Remote-Zugriff angefordert und bekommen.
Fünf Tage lang tat sich nichts, dann sah ich, dass der Backup-Job mit der aktuell installierten HBS3-Version 23.1.1116 (mit der der Fehler ja nicht auftritt) einmal von Hand gestartet wurde (normalerweise startet er per "Schedule: Auto-Backup" beim Anschluss der Platte) und natürlich mit "Folder mismatch" abbrach, da die USB-Platte nicht angeschlossen war.
Eine halbe Stunde später bekam ich im Ticket die Aufforderung, die Platte anzuschließen und den Fehler zu reproduzieren.
Meine sofortige Rückfrage, ob ich dazu (a) wieder von Version 23.1.1116 auf 24.0.0304 updaten und (b) die Option "Eject after completion" im Job deaktivieren soll, wurde zwei Tage lang nicht beantwortet. (Mein Fehler, ich weiß.)
Jetzt ist die Remote Support Session abgelaufen.
Mal sehn, wann und wie es weitergeht.
Stundenlange Bedenkzeiten von QTS kenne ich, Abstürze mit Neustart des NAS hatte ich noch nicht.
Meine externen HDDs sind allerdings nicht mit FAT32, sondern mit NTFS oder ext4 formatiert, wobei die stundenlangen Bedenkzeiten meinem Eindruck nach vor allem auf den NTFS-formatierten Medien auftreten.
Nunja, wenn man die USB-Spezifikation durchliest, beantwortet sich diese Frage relativ schnell und gründlich.
Da packt einen an manchen Stellen schon das Grausen.
Ich bin jedenfalls froh, dass ich das Zeug nicht implementieren muss.
Aber du hast natürlich Recht, der Standard ist alt genug, dass man meinen könnte, diejenigen, die dafür bezahlt werden, sollten es langsam im Griff haben.
USB und QNAP sind definitiv KEINE guten Freunde
Das kann ich nur bestätigen.
Die Geschwindigkeit der Backups auf lokal angeschlossene USB-Platten schwankt extrem.
Letzte Nacht zum Beispiel 12 Stunden für 50 GB (1,4 MB/s), beim vorhergehenden Lauf auf dieselbe Platte 4 Stunden für 1,6 GB (0,15 MB/s), früher aber auch schon einmal 1:20 für 23 GB (9,8 MB/s - auch nicht gerade berauschend für USB3.)
Dabei gibt es während des Laufs gerne immer wieder mal mehrere Stunden lang Stillstand bei der Fortschrittsanzeige, während die USB-Platte laut `iostat` 100% busy ist.
Zwei von drei Malen bleibt das Backup auch gleich am Anfang bei 5% Fortschritt hängen, bis ich es abbreche und neu starte.
QNAP's Kompatibilitätsliste für externe USB-Platten enthält mehrheitlich Modelle, die es bei keinem mir bekannten Händler zu kaufen gibt, aber wenn man eine benutzt, die nicht auf der Liste steht, verweigert der QNAP-Support jede Unterstützung.
Ich habe mir für Supportfälle mit vieler Mühe extra eine Platte von der Kompatibilitätsliste beschafft.
Genau die ist die fehleranfälligste in meiner Kollektion. (Was natürlich für den Anschaffungszweck perfekt ist.)
Ich frage mich, was die eigentlich bei ihren Kompatibilitätstests testen.
Naja, ist schwierig, wenn mehrere Leute auf der gleichen DB arbeiten sollen
Dafür ist Access sowieso nicht geeignet. Sowohl offiziell vom Hersteller nicht unterstützt als auch real in der Praxis als Quelle von Datenverlusten nachgewiesen.
Support hat mir eine ältere Version zur manuellen Installation geschickt. (23.1.1116)
Mit der läuft es jetzt erstmal wieder.
Er will sich melden, wenn es eine neuere Version zum Testen gibt.
Bis dahin soll ich nicht wieder auf die nach wie vor im AppCenter angebotene Version 24.0.0304 updaten, auch wenn mich das NAS jetzt täglich nervt, dass es da doch ein Update gebe.
Außerdem wird mir auch oben keine Anzahl der Prozesse angezeigt.
Dort steht alles auf 0.
Das ist ja schon ein deutliches Zeichen dafür, dass diese Anzeige nicht ernstzunehmen ist.
Dass sie dann auch noch eine CPU-Last durch Zombieprozesse anzeigt, würde ich schlicht als weiteren Anzeigefehler ignorieren.
Wenn dem so ist, warum habe ich dann Zombies die den CPU belasten?
Keine Ahnung, was QNAP da anzeigt. Ich würde mal per ssh auf der Linux-Kommandozeile nachschauen, was da wirklich Sache ist.
