Beiträge von tgsbn
-
-
Ja, schon. Aber dann darf einem das System doch nicht bei einem Restore komplett um die Ohren fliegen wie vom OP beschrieben.
-
Dann hast Du nur den zweiten Befehl ohne den ersten eingegeben.
Allerdings ist du aufs Root-Verzeichnis bei QTS aufgrund der speziellen Volume-Struktur auch nicht unbedingt sinnvoll.
Ich empfehle da eher bei /share anzufangen.
Darunter liegen die Datenverzeichnisse.
Außerdem würde ich die Option -s nicht nutzen, weil sie die Ausgabe auf die oberste Verzeichnisebene beschränkt.
Ich selbst nutze gerne: du /share | sort -n | tail
Das gibt die 10 größten Ordner aus.
Das sieht dann zum Beispiel so aus:
Code
Alles anzeigen[~] # du /share | sort -n | tail 104947408 /share/NFSv=4/Multimedia/Music 148931972 /share/CACHEDEV1_DATA/Download 148931972 /share/NFSv=4/Download 174786248 /share/CACHEDEV1_DATA/Multimedia 174786248 /share/NFSv=4/Multimedia 266498952 /share/CACHEDEV1_DATA/Backups/ctWImage-Copy 303536600 /share/CACHEDEV1_DATA/Backups 323718220 /share/NFSv=4 731058392 /share/CACHEDEV1_DATA 1529473992 /share [~] #
Man sieht dass unter /share/NFSv=4 einige Ordner doppelt gelistet werden. (Nämlich genau die per NFS freigegebenen.)
Wenn die Detailtiefe nicht reicht, kann man an das tail noch ein -n 20 oder größer anhängen, um die Anzahl der ausgegebenen Ordner zu erhöhen.
Anm.: Leider kennt das abgespeckte sort von QTS die Option -h nicht, deshalb kann man in dieser Kombi die Option auch bei du nicht verwenden.
-
Ich denke, an dem Punkt ist der QNAP-Support gefragt.
-
Das hier:
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
To ensure system security, QTS now automatically disables applications that are not updated and that do not meet the minimum version requirements.
ist doch nicht neu? Das habe ich doch schon in meinem 4.5.4.1892!
-
Die "CUII-Emfehlungen" für DNS-Filter
habe ich mir gerade mal angeschaut. Da sind ja - haltet euch fest - sechs Domains aufgeführt! Scheint ja sehr rührig zu sein, der Verein.
(Abgesehen davon, dass ich natürlich bei einer 1er-Stichprobe die "zur Sperrung empfohlene" Domain völlig problemlos zu 2x A, 2x AAAA und 1x MX auflösen konnte - es zwingt einen ja niemand, ausgerechnet einen DNS-Resolver eines CUII-Mitglieds zu nutzen.)
-
Außer das Abspielprogramm hat einen Buffer Overflow und erlaubt es dadurch, über eine manipulierte Mediendatei ausführbaren Code einzuschleusen und zur Ausführung zu bringen.
-
Das sind keine Dateien, sondern erweiterte Attribute, die MacOS setzt, wenn man Dateien aus dem Internet lädt, um Dich später zu warnen, dass sie nicht aus vertrauenswürdiger Quelle stammen. Der Mechanismus entspricht dem, was Windows in den Dateieigenschaften als "Die Datei stammt von einem anderen Computer. Der Zugriff wurde aus Sicherheitsgründen eventuell blockiert." anzeigt.
Entfernen kann man dieses erweiterte Attribut ebenfalls unter MacOS mit dem Kommandozeilenbefehl xattr -d com.apple.quarantine <dateipfad> bzw. rekursiv in einem ganzen Verzeichnisbaum mit xattr -rd com.apple.quarantine <verzeichnispfad>.
Ich dachte, ich hätte in HBS3 eine Option gesehen, erweiterte Attribute auszuschließen, aber ich kann sie gerade nicht finden. Vielleicht habe ich das nur geträumt.
-
Wenn es wirklich die RAM-Belegung ist, lügt der Resource Monitor.
Der zeigt bei Memory Usage 54-56% Used an.
Qboost behauptet, es seien noch 10-15% Free Memory.
top meldet:
Mem: 832684K used, 173396K free, 13604K shrd, 7984K buff, 250968K cached
Die Container Station belegt stabil 190 MB, wenn keiner der beiden Container läuft. (Also die meiste Zeit.)
Wenn einer der Container-Cronjobs startet, steigt das um ein paar MB an, und wenn der Container seinen Job erledigt hat, geht es brav wieder auf den alten Wert zurück.
ClamAV habe ich nach kurzer Erprobung von der Maschine verbannt, weil es zu viele False Positives produzierte und die Maschine bis zur Unbrauchbarkeit auslastete.
(Wenig verwunderlich, wenn ich sehe, dass der clamd-Prozess auf den "echten" Linux-Servern, die ich administriere, mehrere GB an Speicher belegt, die es auf dem TS-228A nun einmal nicht gibt.)
Mir ist schon klar, dass das TS-228A ein Einsteigermodell ist, von dem man leistungsmäßig nicht allzu viel erwarten sollte.
Und dass QTS eher ein "consumer grade product" ist, bei dem man sich über das eine oder andere Speicherleck nicht wundern darf, habe ich in drei Jahren als QNAP-Nutzer auch gelernt.
Aber für den Heimbereich tut's das.
-
Hängt davon ab, was man alles gleichzeitig auf dem NAS laufen lässt. Bei reinen Speicher-NAS habe ich mir angewohnt so alle 3 Monate einen Neustart durchzuführen.
Auf dem Ding laufen als Dienste: SMB, NFS (ungenutzt, könnte ich eigentlich abschalten), DLNA (MinimServer), Container Station mit zwei per Cron periodisch gestarteten Containern (Log-Backup meiner Fritzbox und IMAP-Backup meines Fastmail-Kontos), HBS3 - das war's. 3 Monate hält es nicht durch. Ich protokolliere zwar nicht, aber geschätzt einmal im Monat muss ich es neustarten, sonst nehmen die Hakeleien überhand.
Erfahrungsgemäss verbessert der Ruhezustand die Stabilität überhaupt nicht.
Logisch, wenn man weiß wie der Ruhezustand bei Linux implementiert ist. Der Stabilität kann so etwas nicht zuträglich sein.
In welchem Intervall tritt den das Problem auf?
Wie gesagt: wenn ich das Gerät länger als einen Monat ohne Neustart durchlaufen lasse, fängt es in der GUI an verschiedenen Stellen zunehmend an zu hakeln. Nichts, wo man sagen könnte: genau jetzt tritt das Problem auf. Eher so eine steigende Häufigkeit von Merkwürdigkeiten wie die eingangs beschriebene. Die Basisfunktionalität (SMB und DLNA) ist aber nicht beeinträchtigt. Deshalb kommt es durchaus vor, dass die Maschine länger durchläuft, bis ich mal wieder irgendetwas auf der GUI machen will und feststelle: oh Mist, zu lange nicht neu gestartet, nichts geht. Dann kann es auch durchaus sein, dass nicht einmal ein Neustart mehr über die GUI geht und ich per ssh oder Power-Knopf neustarten muss.
Welche Firmware ist aktuell installiert?
4.5.4.1892 - das war aber bei den Vorgängerversionen auch schon so.
-
Kein Intel: TS-228A, QTS 4.5.4.1892
-
Localhost ist 127.0.0.1, bitte korrigieren,
127.0.1.1 ist in diesem Fall durchaus korrekt. Da läuft bei QTS ein dnsmasq. Live-Beweis von meinem TS-228A:
Code
Alles anzeigen[~] # ping 127.0.1.1 PING 127.0.1.1 (127.0.1.1): 56 data bytes 64 bytes from 127.0.1.1: seq=0 ttl=64 time=0.182 ms 64 bytes from 127.0.1.1: seq=1 ttl=64 time=0.172 ms 64 bytes from 127.0.1.1: seq=2 ttl=64 time=0.170 ms 64 bytes from 127.0.1.1: seq=3 ttl=64 time=0.165 ms ^C --- 127.0.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.165/0.172/0.182 ms [~] # netstat -paun | grep 127.0.1.1 udp 0 0 127.0.1.1:53 0.0.0.0:* 8810/dnsmasq [~] # nslookup www.cisco.com 127.0.1.1 Server: 127.0.1.1 Address: 127.0.1.1#53 Non-authoritative answer: www.cisco.com canonical name = www.cisco.com.akadns.net. www.cisco.com.akadns.net canonical name = wwwds.cisco.com.edgekey.net. wwwds.cisco.com.edgekey.net canonical name = wwwds.cisco.com.edgekey.net.globalredir.akadns.net. wwwds.cisco.com.edgekey.net.globalredir.akadns.net canonical name = e2867.dsca.akamaiedge.net. Name: e2867.dsca.akamaiedge.net Address: 23.197.7.44 [~] # nslookup www.cisco.com 127.0.0.1 ;; connection timed out; no servers could be reached [~] #
Bei IPv4 ist das ganze Netz 127.0.0.0/8 Localhost, d.h. man kann auf 127.128.129.130 genauso gut mit sich selber reden wie auf 127.0.0.1. Wie man aber im netstat-Output sieht, lauscht der dnsmasq explizit auf 127.0.1.1. 127.0.0.1 funktioniert deshalb nicht.
-
tgsbn hat momentan doch das gleiche / ähnliche Problem oder nicht? Müsste ein Thread von gestern sein...
Du meinst wahrscheinlich das hier:
externe USB-Platte in ssh sichtbar, in der GUI nicht.
Das Problem lag aber deutlich anders: Meine Platte wurde nicht mit 0 Bytes angezeigt, sondern überhaupt nicht. Das Problem trat nicht bei der Rückkehr aus dem Ruhemodus auf, sondern beim Anschließen der Platte. Es ging auch kein Firmware-Update voraus.
-
Zur heutigen planmäßigen Datensicherung habe ich die USB-Festplatte, die an der Reihe ist, angeschlossen, aber der HBS3-Job (Schedule: Auto Backup) lief nicht an.
Das Icon "external devices" in der Titelleiste der GUI zeigt als Mouseover-Text: "No external devices connected"
Wenn ich mich per ssh auf dem NAS einlogge, sehe ich aber in dmesg die Meldungen, dass sie erkannt und eingebunden wurde.
In df sehe ich sie auch als /dev/sdc1, eingehängt unter /share/external/DEV3301_1.
Wenn ich in "Storage & Snapshots" auf "External Storage" klicke, erscheint "Loading..." mit einer Prozentangabe, die über 15 Minuten langsam und stockend bis 99% hochlief und dann stehenblieb.
Da steht sie nun schon eine halbe Stunde.
Dabei zeigt top keine auffällige Systemlast.
Load Average ist von 1.38/1.48/1.60, was für einen Quad Core eigentlich völlig im Rahmen ist.
Die Platte hat bis jetzt immer problemlos funktioniert.
Hat den Effekt schon einmal jemand gesehen?
Followup 2022-02-05:
Nach längerem Stillstand bei 99% hat mich QTS irgendwann wegen Inaktivität abgemeldet. (Trotz regelmäßiger Klicks um genau das zu verhindern.)
Ich habe das NAS daraufhin neu gestartet. Da ich mit Reboots mit angeschlossener externer Platte in der Vergangenheit schlechte Erfahrungen gemacht habe, habe ich vorher per ssh die externe Platte ausgehängt (umount /dev/sdc1) und die USB-Verbindung getrennt.
Der Reboot lief glatt und seitdem ist wieder alles in Ordnung. Die Platte wurde beim Wiederanschließen einwandfrei und schnell erkannt. Der HBS3-Job lief prompt an und fehlerfrei durch. Auch die "Storage & Snapshots"-Seite "External Storage" öffnet wieder wie gewohnt innerhalb weniger Sekunden.
Fazit: Es scheint "nur" das bekannte Problem gewesen zu sein, dass Teile von QTS den Betrieb einstellen, wenn man das System zu lange ohne Neustart durchlaufen lässt.
-
Meinst Du mich? Ich habe kein Update auf QTS 5 bekommen.
-
Hier liegt der Fehler eindeutig vor dem Computer.
Liegt? Meinst, die sind schon so blau, dass sie nicht mehr sitzen können?
Nur hat das bis jetzt wohl niemand kontrolliert und gestört.
Ich bin offenbar niemand.
SCNR
-
Das BSI ist für mich nicht maßgebend.
Dann erst recht. Alle anderen haben schon viel länger erkannt, dass erzwungene Passwortwechsel nach Zeitablauf für die Sicherheit kontraproduktiv sind. Viele, mit denen ich diese Diskussion geführt habe, haben sich eben lange Zeit darauf zurückgezogen, das sei eben die BSI-Empfehlung. Aber dieses Argument ist mittlerweile weggefallen. Daher meine wohlüberlegte Formulierung: selbst das BSI.
Aber wenn Du auf die Policy keinen Einfluss hast, ist die Diskussion hier natürlich müßig.
-
Seufz. Gerade habe ich am Arbeitsplatz noch mit Befriedigung festgestellt, dass keine unserer Samba-Installationen fruit in den VFS Objects stehen hat - und jetzt erwischt mich der CVE privat doch noch.
-
bei denen regelmäßig das PW geändert werden muss
Du hast aber mitbekommen, dass selbst das BSI anlasslose zeitgesteuerte Passwortänderungen nicht mehr empfiehlt?
-
Ja, das ist so. HBS3 mag manchmal aus unerfindlichen Gründen einen Zielordner nicht mehr. Warum, weiß wohl niemand. Falls Deine externe Platte auf der QNAP-Kompatibilitätsliste steht, kannst Du ja mal einen Support Case dafür öffnen. Ansonsten das Allheilmittel: Job unter anderem Namen neu anlegen, dann werden auch neue Sicherungsordner erzeugt. Die funktionieren dann wieder eine Weile.