Ja, ist das originale RAM. Die ersten Fehler sind vor einem halben Jahr aufgetreten. Ich hatte damals aber nicht das NAS in Verdacht und somit existiert da noch ein Support Ticket von. Da war das NAS erst 2,5 Jahre alt.
Beiträge von Xantiva
-
-
Nachtrag: Ja, es wurden Speicherfehler festgestellt ...
Falls noch jemand mal einen Speichertest machen muss - die BIOS-Angaben passen auf der QNAP Seite nicht mehr so ganz. Nach dem ich den USB-Stick eingesteckt hatte, gab es bei mit die folgenden Boot-Optionen:
- QNAP OS
- [General UDisk 5.00]
- [UEFI: General UDisk...] <= Den Eintrag ist richtig!
- [UEFI: Build-in EFI ...]
Laut Anleitung sollte man den 2. Eintrag nehmen. Wenn ich das mache bootet das NAS nicht mehr. Ich musste den 3. Eintrag auswählen!
Mal schauen, was der Support nun mit der Garantie macht - das NAS ist jetzt genau drei Jahre alt geworden.
-
Entspricht das Paperless-NGX den Anforderungen der GoBD?
Scheint eher nicht so zu sein, wenn ich das hier überfliege: Is paperless-ngx a GoBD-conform data-management-system?
-
Nein, die Logs von robocopy zeigen eben nichts, aber das vergleicht ja auch die Dateiinhalte nach dem Kopieren nicht mehr. Es gab wohl von Microsoft noch das File Checksum Integrity Verifier (fciv) Tool, aber das wird nicht mehr angeboten. XCopy prüft bei einen /v wohl auch nur die Dateigrößen, die waren aber i.d.R. identisch.
Ich gehe auch nicht von einem Robocopy Problem aus. Ich hatte beide NAS im Netz und dann auf meinem PC robocopy laufen. Ich vermute, dass das NAS die Daten von der Platte in den teilweise defekten Speicher gelesen hat und dann übers Netz die korrumpierten Daten an meinen Rechner gesendet hat. Je größer die Dateien waren, desto wahrscheinlicher die Kopierfehler. Bei den ecoDMS Daten files von 500 MB waren z. B. 15 unterschiedliche nach dem ersten kopieren. Dann habe ich die 15 nochmal kopiert und verglichen, dann waren es nur noch 5 mit Unterschieden. Dann nur noch 2 und die wurden dann auch fehlerfrei kopiert.
Ok, ein Doppelklick im Browser ist schon eher ungewöhnlich. Da bin ich nicht drauf gekommen.
Danke.
-
Wegen dem vermutlichen Speicherproblem wollte ich die Daten so nicht kopieren bzw. dann erst noch neue Funktionen (rsync Server) aktivieren.
Ich habe jetzt die Daten erst mal alle per robocopy kopiert und dann mühsam per WinMerge verglichen. Da gab es durchaus einige mit Kopierfehlern. Die habe ich dann teilweise mehrfach kopieren müssen, bis das sie fehlerfrei übertragen wurden.
Hm, ich finde keine Möglichkeit das Thema als erledigt zu markieren?
-
Hi,
ich habe vermutlich Speicherprobleme mit meinem TS-253-D (anderer Thread), weswegen ich ein kurzfristig ein neues TS-253-E aufgesetzt habe. Beim Kopieren der Daten kommt es immer mal zu Übertragungsfehlern, so dass ich immer kopieren und dann noch vergleichen muss. Mit den Daten bin ich so weit durch, jetzt fehlt mir das ecoDMS, das auf der Containerstation lief ...
Ich habe die Dateien soweit kopiert und den Container (ecodms/allinone-18.09) eingerichtet. Beim Starten des Containers kommt aber die folgende Fehlermeldung:
CodeError creating db objects: Cannot create PoolableConnectionFactory (Connection to 127.0.0.1:17002 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.)
Komplette Meldung:
Code
Alles anzeigen[ OK ] Sprache: de_DE.UTF-8 * Starting domain name service... bind9 [ OK ] ###INFO### Image wurde erzeugt: 2023-08-17-11:21:22 ###INFO### user ecodms exists setfacl: /srv/data: Operation not supported PSQL database exists checking Version ... PSQL VERSION: 10 ... ok Workdir exists Container Verzeichnis existiert Ocr-Container Verzeichnis existiert Scaninput already points to /srv/scaninput Backup already points to /srv/backup Restore already points to /srv/restore waiting for server to start..... stopped waiting pg_ctl: could not start server Examine the log output. ###INFO### Postgrescheck bereits durchgeführt: 2023-12-18-22:31:00 ###INFO### ecoDMS Server startet as service "de.ecodms.plugin.Db.PooledStorageEndpoint | rollbackTransaction | 2023-12-19 00:05:58,048 | WARN| WARNING: No transaction started!" "de.ecodms.server.EcoDMSServerBootstrap | main | 2023-12-19 00:05:58,059 |ERROR| Error creating db objects: Cannot create PoolableConnectionFactory (Connection to 127.0.0.1:17002 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.)" "de.ecodms.server.EcoDMSServerBootstrap | main | 2023-12-19 00:05:58,064 | INFO| End" "Unable to start up"
Das sind die eingestellten Port-Weiterleitungen:
Beim Netzwerk habe ich sowohl NAT getestet (laut ecoDMS Anleitung) und auch Bridge, wie hier im Forum in der Anleitung beschrieben ecoDMS auf QNAP installieren - macht keinen Unterschied.
Bislang erfolgte der Zugriff immer über die IP vom NAS und Port 17001.
Hat jemand eine Idee? Irgendwie habe ich das Gefühl, ich sehe im Moment den Wald vor lauter Bäumen nicht mehr.
Danke & Ciao,
Mike
Einmal drüber schlafen und ...
- Für die Daten hatte ich ein Verzeichnis in dem Freigabeordner erstellt, statt wie bisher unter /Container. Die gesicherten Daten wieder nach /Container/ecoDMS-Daten kopiert und als Benutzergruppe die Administratoren eingestellt.
- Netzwerk NAT
- Wenn man dann beim Versuch sich mit dem Connection Manager zu verbinden einen Unknown Error 01 (oder so ähnlich) bekommt, dann hat man nicht das passende Image. Ich brauchte z.B. genau die Version "ecodms/allinone-18.09:18.09-3-1"
Jetzt läuft ecoDMS wieder und ich kann den Client wieder öffnen.
-
Auch wenn die Frage schon etwas älter ist, hier die Lösung der Vollständigkeit halber. Die Mountpfade sind in den erweiterten Einstellungen im Bereich Speicher zu finden. Dort sind sie allerdings etwas versteckt! Man muss die Kombobox bei der Speicherzuordnung aufklappen ...
-
Kurze Rückmeldung:
Der 1. Level Support konnte den Fehler auch nicht beheben, hat das Ticket aber dann an die Entwicklung weiter geleitet. Der Mitarbeiter konnte es zumindest temporär beheben:
Zitat von QNAP SupportThe pool and volume have returned to a normal state; however, a minor error persists in the filesystem. So please ask customer to backup the data and then run a filesystem check.
here meta data got corrupted due to unexpected shutdown.
Based on the logs, it seems there might be an issue with memory. So please ask customer to perform a memory test to further diagnose and address the problem.Man vermutet ein Speicherproblem, was dann dafür gesorgt hat, dass das System nur noch auf Power Off reagiert hat. Dabei sind dann die Meta Daten korrumpiert worden.
Ich setze gerade das neue NAS auf und sobald die erst Raid-Synchronisierung durch ist, fange ich an die Daten rüber zu kopieren. Das HBS 3 funktioniert auf dem alten NAS nicht mehr, kann nicht mehr geöffnet werden.
Was ist denn die sicherste Methode, die Daten sauber von einem NAS zum anderen zu bekommen? Robocopy auf dem PC? Oder könnte ich die beiden NAS per 2. Netzwerk-Karte 1:1 verbinden und dann dort mit einer App auf dem neuen NAS die Daten vom alten NAS kopieren?
Danke,
Mike
-
Das Ticket bei QNAP habe ich gestern gleich eröffnet.
Die wichtigsten Daten liegt nochmal synchronisiert in der Cloud, aber eben nicht alle und bis das alles auf einem neuen System wieder eingerichtet ist, vergehen auch viele Stunden.
-
Der Menüpunkt "Speicherpool verbinden und wiederherstellen." ist nicht aktiv. Liegt vielleicht daran, das auf der ersten Platte immer noch nach fehlerhaften Blöcken gesucht wird (83%)?
Auch wenn der Test abgeschlossen ist, bleibt der Menüpunkt deaktiviert:
-
Hallo,
ich nutze ein TS-253D mit zwei 4TB HDD. Vor ein paar Wochen gab es schon einmal Problem mit dem HBS3, doch nach Update der App und einem Firmwareupdate lief das System erst mal wieder fehlerfrei.
Dann hing eine Synchrionisation seit 2 Tagen. Die habe ich gestoppt und wollte dann einmal das NAS neustarten, um dann erneut die Synchronisation anzustossen. Das NAS konnte aber schon nicht mehr stoppen. Es wollte 15 Prozesse stoppen, aber als sich nach einer halben Stunde nichts getan hat, habe ich das NAS über den Power-Button ausschalten müssen. Nach dem Einschalten:
Der Speicherpool ist entladen:
Aber der Status der Datenträger ist scheinbar noch gut:
Die Daten habe ich auf der Konsole abgefragt, wobei die mir leider nicht sonderlich viel sagen. Ob die Warnung des pvscan ein Problem sind - keine Ahnung.
Code
Alles anzeigen[~] # cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md1 : active raid1 sda3[0] sdb3[1] 3897063616 blocks super 1.0 [2/2] [UU] md322 : active raid1 sdb5[1] sda5[0] 6702656 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md256 : active raid1 sdb2[1] sda2[0] 530112 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md13 : active raid1 sda4[0] sdb4[1] 458880 blocks super 1.0 [64/2] [UU______________________________________________________________] bitmap: 1/1 pages [4KB], 65536KB chunk md9 : active raid1 sda1[0] sdb1[1] 530048 blocks super 1.0 [64/2] [UU______________________________________________________________] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Code
Alles anzeigen[~] # md_checker Welcome to MD superblock checker (v2.0) - have a nice day~ Scanning system... RAID metadata found! UUID: 02f8c70f:a93090e7:7b135312:8012e420 Level: raid1 Devices: 2 Name: md1 Chunk Size: - md Version: 1.0 Creation Time: Oct 29 00:08:08 2020 Status: ONLINE (md1) [UU] =============================================================================================== Enclosure | Port | Block Dev Name | # | Status | Last Update Time | Events | Array State =============================================================================================== NAS_HOST 1 /dev/sda3 0 Active Dec 10 17:34:41 2023 6205 AA NAS_HOST 2 /dev/sdb3 1 Active Dec 10 17:34:41 2023 6205 AA ===============================================================================================
Code[~] # pvscan WARNING: duplicate PV biHZcZOuMcMyhu3gUSaYj3ttDHYNtcb8 is being used from both devices /dev/drbd1 and /dev/md1 Found duplicate PV biHZcZOuMcMyhu3gUSaYj3ttDHYNtcb8: using /dev/drbd1 not /dev/md1 Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1 WARNING: duplicate PV biHZcZOuMcMyhu3gUSaYj3ttDHYNtcb8 is being used from both devices /dev/drbd1 and /dev/md1 Found duplicate PV biHZcZOuMcMyhu3gUSaYj3ttDHYNtcb8: using /dev/drbd1 not /dev/md1 Using duplicate PV /dev/drbd1 from subsystem DRBD, ignoring /dev/md1 PV /dev/drbd1 VG vg1 lvm2 [3.63 TiB / 0 free] Total: 1 [3.63 TiB] / in use: 1 [3.63 TiB] / in no VG: 0 [0 ]
Was könnte ich jetzt noch machen? (Ich werde jetzt vermutlich gleich ein neues NAS bestellen, weil ich dem nicht mehr traue, auch wenn das noch mal als laufen kommt. Aber bis ein neues da ist, wird das entsprechend dauern.)
Danke,
Mike
-
Nein, das wurde nicht migriert. Ich habe jetzt sowohl das HBS3 aktualisiert, wie auch das FW-Update gemacht. Für den RAM-Test muss ich mir erst noch mal temporär einen Monitor organisieren.
-
Sind nicht eher Softwarefehler die Ursache für solche fehlerhaften Speicherzugriffe? https://en.wikipedia.org/wiki/Segmentation_fault
Code
Alles anzeigenModel: TS-253D Firmware: 5.1.1_20230815 Execute Test: N/A Test Status: N/A Test Description: N/A Error Log Count: 29 Segfault: 57 MD9 FS Error: 0 MD0 Status: active Kernel: Linux version 5.10.60-qnap CPU: Intel(R) Celeron(R) J4125 CPU @ 2.00GHz
In den log finde ich segfaults in:
\mnt\HDA_ROOT\.logs\kmsg
Code2023-10-20 06:01:31 +02:00 <6> [3894936.657117] python[24670]: segfault at 10000008 ip 00007f879f883380 sp 00007fff72092d28 error 4 in libpython2.7.so.1.0[7f879f741000+1b3000] 2023-10-20 06:03:38 +02:00 <6> [3895063.080439] python[26714]: segfault at 10000008 ip 00007f9e95c9a380 sp 00007fffc6c43d58 error 4 in libpython2.7.so.1.0[7f9e95b58000+1b3000] 2023-10-20 06:05:55 +02:00 <6> [3895200.001587] python[29256]: segfault at 7fa29c1413c8 ip 00007fa28beca380 sp 00007ffe06a5b218 error 4 in libpython2.7.so.1.0[7fa28bd88000+1b3000] 2023-10-20 06:27:11 +02:00 <6> [3896476.488628] python[19619]: segfault at 10000000 ip 00007f212ce88009 sp 00007ffc4a99fdb0 error 6 in libpython2.7.so.1.0[7f212cddc000+1b3000]
und im \tmp\klogd_dump.log
Code2023-11-17 10:03:15 +01:00 <6> [6332255.710783] python[15116]: segfault at 11988020 ip 00007f91de987380 sp 0 2023-11-17 10:07:07 +01:00 <6> [6332487.444890] dnsmasqd[8639]: segfault at 7f5797978390 ip 00007f579030fedd sp 00007fffa8b88070 error 4 in libpython2.7.so.1.0[7f579026e000+1b3000] 2023-11-17 10:10:37 +01:00 <6> [6332698.090116] python[22907]: segfault at 10000008 ip 00007f1b56cee380 sp 00007fff84ace938 error 4 in libpython2.7.so.1.0[7f1b56bac000+1b3000] 2023-11-17 10:10:58 +01:00 <6> [6332718.912613] python[23240]: segfault at 7fbed1c2cf08 ip 00007fbec18476a0 sp 00007fff355a4910 error 4 in libpython2.7.so.1.0[7fbec17b0000+1b3000] 2023-11-17 10:11:08 +01:00 <6> [6332728.963541] gwd[3994]: segfault at 7f57979bf4b8 ip 00007f57903b0380 sp 00007fffa8b885b8 error 4 in libpython2.7.so.1.0[7f579026e000+1b3000]
-
Antwort vom Support:
- Man hat RAM-Fehler festgestellt (679) und ich soll ein Memtest laufen lassen.
- Und den Flash-Speicher soll ich auch prüfen ...
Mir war so, als hätte ich das mit dem RAM-Test irgendwo hier als "Standard-Antwort" vom Support gelesen?
Kann ich die Memoryfehler in den übermittelten Logfiles irgendwie mal selber nachvollziehen?
Mal schauen, dass ich das morgen prüfen kann. Wobei es gestern noch ein HBS3 Update gab und der Fehler bislang noch nicht wieder aufgetreten ist.
-
Nur seit gestern früh meldet HBS3 für einen ActiveSync-Job andauernd Verbindungsprobleme zur Dropbox. ...
Bis zur 5.1.2.2533 lief das alles ohne Probleme, andere Änderungen am Netzwerk kann ich ausschließen. ...
Bin gerade auf den Eintrag aufmerksam gemacht worden. Bei mir (noch mit FW 5.1.1.2491) hat sich das NAS - vermutlich durch das HBS 3 - auch schon 2x komplett aufgehängt. Es wird per RSync in die Cloud (HiDrive) synchonisiert. Hat also vielleicht nichts mit der 5.1.3 zu tun ...
-
Firmware Version: 5.1.1.2491, zuletzt am 17.11. geprüft.
Danke, ich schau nach dem Thread.
-
Ich habe gerade ein ähnliches Problem mit dem HBS 3 (Version 23.0.0921). Bei mir wird seit Jahren täglich per RSync in die Cloud synchronisiert. in den letzten Tagen ist es 2x passiert, dass das NAS nicht mehr reagiert hat. Die Platten rödeln noch, aber Webinterface oder die freigegebenen Laufwerke sind nicht mehr zu erreichen. Es hilft nur das NAS aus- und wieder einzuschalten. Ein Tag zwischendurch läuft das Update ohne Fehler und dann hängt es wieder. Manuell ist es auch wieder fehlerfrei durchgelaufen.
Ticket bei QNAP ist erstellt.
-
Hi David,
Zitat von "Terz"Das Problem auf dem NAS ist, das es nicht für die Dauer hält... Wahrscheinlich nur bis zum nächsten FW update.
OK, wie verhält sich das dann z. B. mit den mySQL Datenbanken? Die liegen per default unter /share/MD0_DATA/.@mysql/ und sollten auch nach einem FW Update vorhanden sein, richtig?Zitat von "Terz"Was ich empfehlen kann, wäre eine VM Ware Server (VM). MIt ubuntu server. Da dann alles konfiguiert, und los geht's.
Den VM Ware Server lokal auf dem PC und wo würdest Du dann die Virtuellen Maschine(n) speichern? Auf dem NAS, oder lokal ablegen und regelmäßig auf das NAS sichern?Ciao,
Mike -
Ok, was ich mir so gedacht habe ...
Ich sitze hier vor einem Windows - PC. Bislang habe ich lokal mit XAMPP einen lokalen Webserver (mit Xdebug und PHPUnit) und mit VisualSVNSever meine Repositories "betrieben". Entwickelt habe ich dann mit Netbeans. Nun schwebt mir halt vor, meinen PC zu "entlasten" und den Webserver (wieder mit XDebug und PHPUnit) auf den QNAP zu packen. Subversion habe ich schon installiert bekommen.
Was mir noch fehlt ist jetzt der Webserver MIT Xdebug und PHPUnit ...
In die Richtung sozusagen ...
Ciao,
Mike -
Zitat von "Terz"
Du hattest Dir aber auch vorher schon den apache und die php extensions installiert und den default apache deaktiviert?
Oh Mann, natürlich nicht. Gibt es hier irgendwo eine Linux - Ecke für Dummies? Oder jemanden, der mich - gegen eine Spende fürs Forum - mal kurz an die Hand nimmt und die erforderlichen Schritte aufzählt?Ciao,
Mike