Beiträge von blausand

So, jetzt mal schön festhalten.

Die Liste im ersten Posting dieses Threadds klingt ja famos nach "Bitte nicht benutzen!", und demnach haben wir alle ja fleißig abgeschaltet was das Zeug hält, und noch ein bisschen mehr.

Kein Nextcloud, kein Samba, ja alles deaktiviert. Mit bösem Zauber das Gerät gelähmt:

[~] # /etc/init.d/services.sh stop

Ja, kein Wunder: Dann gibt's natürlich auch kein IOtop mehr und keinen webserver und kein Management.

Ahaaaaber.

Meine Ohren sind gut genug, um mit Bestimmtheit zu sagen:

[~] # /etc/init.d/thttpd.sh stop

lässt die Platten ruhen und

[~] # /etc/init.d/thttpd.sh start

lässt sie wieder alle 5s rattern.

Der eingebaute, tiny, tiny http-Deamon, das erste also, was man nach der secure shell laufen haben will, kriegt QNAP schon nicht ohne krassen Plattenkrieg hin.

Was zum heiligen Geier?

Liegt es an dem php-fpm-proxy?

Ist das bei Euch anders? #wollndochmalsehn

Kann es einfach nicht fassen. Kann es einfach nicht fassen. Es ist eine GRUNDFUNKTION, ey.

Möchte mir jemand nach zehn Monaten eine Antwort schenken bitte?

Ich lass meine Fritz!Box sich bei Strato melden, damit eine subdomain immer nach Hause zeigt. Das funktioniert soweit prima. Ich erreiche meine QNAP per 80 und per 443.

ABER.

Strato nimmt zwar für Wildcard-SSL-Zertifikate Geld, laut Kundendienst von QNAP sollte es aber nichts damit zu tun haben, dass ich den hier thematisierten Fehler beim Einrichten von Let's Encrypt SEIT JAHREN nicht wegbekomme.

Ich habe mehrmals alles durchprobiert (zusätzlichen webserver im Backend deaktiviert/aktiviert) und an mehreren Stellen um Hilfe gebeten.

Die Ports sind offen, die Fritz!Box leitet super weiter. Was könnte noch das Problem sein?

Zitat von RedDiabolo

PS.: Mein Win10 hat mehre tausend Zugriffe pro Minute auf die Systemplatte, auch wenn ich GAR NICHTS mache! Wieso sollte das Linux auf deiner NAS so eben mal Stundenlang ohne einen einzigen Zugriff auf die Disk laufen können?

So tief sind wir also gesunken, ja?

Ich frage mich: Wozu haben wir eigentlich Arbeitsspeicher, virtuelle Laufwerke in selbigem, dutzende Cache-Techniken, inzwischen physisch IM Laufwerk, wenn wir selbst diesen Grenzfall "NAS" nicht hinbekommen, wo wir SELBSTREDEND wollen, dass die Platten runterfahren, wenn Stundenlang kein Aas mit Überraschungszugriffen daherkommt?

Ich meine: So eine Metadatenbank für Filme und Musik und ein paar dutzend Kalender und Adressbücher - das alles kann doch bitte im RAM gehalten werden und ein-zweimal am Tag runtergeschrieben?

Außerdem: Wozu gibt es fancy "Control Screens" und "Device Manager", wenn nicht mal die Prozesse festgenagelt werden können, die hinter solchen Zugriffen im Sekundentakt stecken?

Und woran liegt es, dass die vermaledeiten LEDs selbst beim kritischen Festplatten-Schluckauf ihren Status auf konstant GRÜN belassen?*

Nee, nee. Das QTS ist hier alles andere als ausgereift.

* Zweimal passiert: HD3 und HD4 (von 8 ) melden GLEICHZEITIG per Beep und per Display Absenz, leuchten aber grün - und sind nach Neustart wieder normal da.

Danke, dr_mike, für den Verweis meiner Anfrage in diesen Sammelthread. 

Wäre ein Monitoring mit dem Skript denn in meinem Fall weiter zielführend?

Ich denke, dass ich mit meinen reportierten Dateien bereits recht nahe an der Problemursache bin, oder?

Ganz vorsichtig möchte ich auch fragen, warum bei gefühlt 23 System- & Kontrolldialogen eine Diagnose dieses Verhaltens nicht zum Kern eines NAS-Betriebssystems gehört?

@all : Statt eines Spoilers einfach der Link auf die Fragestellung:

/var/log/hal_lib.log quillt über vor lauter Fehlermeldungen

Ich bin von dem gleichen Problem betroffen und bitte um Beantwortung dieser Frage.

Folgende log files werden minütlich angefasst um jeweils Meldungen nach dem gelisteten Muster anzuhängen und lassen daher keine Festplatten einschlafen:

hal_lib.log:

2019-01-20 10:18:13 [ 591 hal_daemon ] id = 1, name = SATA_R-Error_Count, status_flag = 0x32, value = 200,worst = 200, thresh = 0,raw = 0
(repeating for id = 2~199)
2019-01-20 10:18:13 [ 591 hal_daemon ] id = 200, name = Multi_Zone_Error_Rate, status_flag = 0x8, value = 100,worst = 253, thresh = 0,raw = 0
2019-01-20 10:18:21 [ 591 hal_daemon ] GPIO_Set_NAS_Status_LED: event = 0x1000,status = 0, value = 0x0, formatting_count = 0
2019-01-20 10:18:21 [ 591 hal_daemon ] GPIO_Set_NAS_Status_LED: event = 0x2000,status = 0, value = 0x0, formatting_count = 0

storage_lib.log:

2019-01-20 10:15:21 [29256 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:23 [29314 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0xffb830, 772).
    2019-01-20 10:15:23 [29314 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:26 [29335 authLogin.cgi ] Perform cmd "/bin/mount | grep "/mnt/HDA_ROOT" &>/dev/null" OK, cmd_rsp=0, reason code:0.
    2019-01-20 10:15:31 [29378 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0x16da110, 772).
    2019-01-20 10:15:31 [29378 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:33 [ 591 hal_daemon ] Volume_Enumerate_Data_Volumes: got called with (0x7f3124001240, 772).
    2019-01-20 10:15:33 [ 591 hal_daemon ] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:34 [29420 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0x1d95830, 772).
    2019-01-20 10:15:34 [29420 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.

SDMD.log:

SDM: start predict enc = 0 port = 1 device
SDM_Health_Predict:Start to predict sata disk
(repeating two lines for port = 2 ~8 device)
SDM: scan 32th enc, total enc = 4
SDM: enc = 32 is not internal.
SDM: scan 33th enc, total enc = 4
SDM: enc = 33 is not internal.
SDM: scan 34th enc, total enc = 4
SDM: enc = 34 is not internal.

ini_config.log:

Ini_Conf_Remove_LCK_File: lck file /var/lock/INI_L2V0Yy92b2x1bWUuY29uZg==.lck does not exist!

Muss eventuell das manaRequest-script seltener ausgeführt werden?

Verbirgt sich dahinter ein Flush-Vorgang?
Liegt alles an falschem Journalling?

Muss ich mein QNAP NAS bei myqnapcloud.com anmelden, um ein Let's-Encrypt-Zertifikat installieren zu können?

Ich wollte es direkt für seine URI als subdomain meiner domain zertifizieren.

Damit scheitert allerdings der QTS-Einrichtungsdialog für ein Let's-Encrypt-Zertifikat - selbst wenn die ports 80 und 443 offen sind.

Hallo,

gilt das auch für subdomains, die man beim hosting Anbieter direkt für DynDNS eingerichtet hat, wie es z.B. bei Strato geht?

Ich hab ein bisschen Angst, dass es daran liegt, dass die Hauptdomain auf dem Strato-Server endet und daher auch das DNS für die Subdomains über Strato geht, und die das Funktionieren von Let's Encrypt irgendwie unterbinden, weil sie Einbußen sehen, wenn da jetzt jeder mit seinem popeligen Hostingpaket 500 subdomains einrichten kann und alle fein trotz DynDNS mit Let's Encrypt sicher machen. Kann das sein?

(Selbstredend: Ja, ich habe auch den oben genannten Fehler und zwar auf einer TS-869pro mit QTS 4.3.4.0435. Inzwischen hab ich alles ausgeschaltet und den Administrationszugang zurück auf Port 80 und optional 443 gesetzt, was auch funktioniert und in der Fritz!Box 1:1 durchgeleitet wird.)

Mensch @fredz!

Man kann ja immer was dazulernen, wenn man dem Clickbait von Foristen aus der IT-Branche folgt, aber - meine Fresse! - wieviele Leser haben hier inzwischen sinnlos IT-Zeit verloren?

Vielleicht solltest Du dennoch dem Titel des threads ein "[HOAX] " voranstellen. Finde ich.

Geil!
Wie hast'n überhaupt sabre da drauf gekriegt? Gibt's ein QPKG oder haste eins gebaut?
Oder mit zwei Nadeln den Code irgendwie in das QNAP OS gestrickt?

Danke, würde das gerne auch so machen, anstatt für Card/CalDAV durch 'ne Nextcloud gehen zu müssen.