Beiträge von qcamber

tiermutter
und wenn ich mich an den "alten" Platten ausgetobt habe, die derzeitigen Platten wieder rein und fertig?

Zitat von tiermutter

Warum und wie wurden die Disks ausgebaut?

tiermutter
Zur Frage:
die Daten wurden aus Versehen gelöscht. Danach, sofort (also im Anschluss), die 6 betroffenen Platten, gegen Austauschplatten über die Neuinitialisierung, gewechselt.
Damit hat sich an den Einstellungen nichts geändert.
Die "neuen" Platten ersetzen lediglich die "alten" Platten. Systemseitig bleibt alles beim alten. Außer, dass das Ganze jetzt eine Zeit her ist.
Ja ich kenne die Konfig, an der habe ich damals zu heute, alte zu neue Platten, nichts geändert.
Raid 6; 0 (Sechs; Null)
1x Speicherpool
2x Thin-Volume

Hi, ich brauche bitte mal Eure Sicht der Dinge.
Ich habe 6 Festplatten, auf denen sich Daten befinden die "gerettet" werden sollen.

--
Dafür soll direkt auf die NAS zugegriffen werden (UNIX/Linux).
Die 6 Platten sind waren im NAS vor ca. 2 Jahren, heißt alte Firmware usw.

Was ist der Plan?

• NAS mit den jetzigen Platten ausschalten
• Platten raus
• "alte" Platten in die NAS einbauen, einschalten
• Rettungsversuch unternehmen
• entweder Erfolg oder Mißerfolg
• danach ausschalten
• alte Platten wieder raus
• jetzige Platten wieder rein
• Einschalten und hoffen das alles cool ist

Kann das funktionieren oder laufe ich Gefahr, nicht mehr auf die jetzigen Platten zugreifen zu können?

Hat jemand eine Rückmeldung zu QVPN und den Verbindungsanzeigen?
Wie könnte ich denn noch prüfen, ob QVPN mit der Config das tut was es soll?

Ich habe die 2 Config gemischt:

1. die funktionierende "Alte" > funktionierend insofern, dass sie in QVPN geladen wird und nutzbar wird
2. die nichtfunktionierende "Neue"

Das sieht dann so aus:

client
dev tun
proto udp
remote ***
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
verify-x509-name *** name
auth-user-pass
comp-lzo
keepalive 10 60
verb 3
auth SHA256
cipher AES-256-GCM
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA


<crl-verify>
-----BEGIN X509 CRL-----
***
-----END X509 CRL-----
</crl-verify>


<ca>
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
</ca>


disable-occ

Das wird von QVPN als Config angenommen. Ich kann es auch starten ohne einen Fehler im Log.
Ich kann es jedoch über die UI nicht verifizieren, da die Anzeigen nicht mehr passen.
Verbindungsprotokoll wird nicht erstellt. Im Überblick gibt es kein Up- und Download bei VPN. Bei den Verbindungsprofilen wird kein "grünes Licht" mehr angezeigt.
QVPN 3.2.98

QTS 5.1.4.2596

pasted-from-clipboard.png    pasted-from-clipboard.png

ich habe die genannten raus genommen. Der Fehler bleibt. Ich habe eine config (siehe unten) von 2020, die wird ohne Probleme geladen:
Die hat offensichtlich kein crl verify.
Nehme ich nur das crl verify aus der neuen config raus, wird sie immer noch nicht von QVPN geladen.

client
dev tun
proto udp
remote ***
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
verify-x509-name *** name
auth-user-pass
comp-lzo
keepalive 10 60
verb 3
auth SHA256
cipher AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA


<ca>
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
</ca>

Okay, probiere ich das.
tiermutter wo finde ich das "was nicht zwingend benötigt wird"? Steht das irgendwo?

Hallo zusammen,
ich frage mal hier weiter. Ich habe keinen Ansatz dazu, weil die
config nicht gleich ist, derer die ebenfalls ein Thema damit haben.
Die config ist mit dem Fehler:

"Diese Datei enthält falsche Parameter.."

client
dev tun
proto tcp
remote ***
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-gcm
ncp-disable
tls-client
remote-cert-tls server


auth-user-pass
compress
verb 1
reneg-sec 0
<crl-verify>
-----BEGIN X509 CRL-----
***
-----END X509 CRL-----
</crl-verify>


<ca>
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
</ca>


disable-occ

Ahoi,

gibt es dazu eine Lösung? Meine OpenVPN Config´s werden gar nicht angenommen. Wie beschrieben:

"Diese Datei enthält falsche Parameter. Bitte bearbeiten Sie die Datei oder laden Sie eine andere hoch (*.ovpn)"

@MarGol
liest sich auch gut, danke für die Information, dass probiere ich mal aus.

Ja, das ist möglich. Kann man so sehen.
In meiner Welt habe ich ein Angebot/Vorschlag gemacht und QNAP hat abgelehnt. Das ist auch in Ordnung für mich.
Natürlich könnten sie den Tausch streichen und sie könnten auch reparieren. Jedoch weiss ich, dass in unserer Zeit dieser "Aufwand" nicht mehr oder äußerst selten betrieben wird.

@sammy229
ja, kann man so sehen.
Ich sehe es nicht so. Das NAS ist defekt, nicht aufgrund einer Abnutzung durch Nutzung, sondern aufgrund eines "Baufehlers" der Hardware.
So oder so ähnlich habe ich es jedenfalls verstanden. Das ändert die Situation, in meinem Verständnis.
Damit möchte ich es auch belassen. Wie gesagt, QNAP hat die Möglichkeit darauf einzugehen oder grundsätzlich zu verneinen. Ich kann mit beidem leben.

Danke an alle fürs Mitdiskutieren.
Ich bestehe nicht wirklich darauf, ich habe nur die Argumentation darauf hin gelenkt, quasi eine Anfrage gestellt, ob das möglich ist.
QNAP kann einfach nur sagen "Ja" oder "Nein"
Ich finde jetzt meinen Ansatz nicht so schlecht oder überzogen.
Ich gehe mal von einem Auto aus. Wenn es hier eine Rückrufaktion gibt, wegen eines festgestellten Mangels, würde ich nach Behebung des Mangels nicht wirklich nach so was wie einer
neuen Garantie fragen.
Wenn jedoch das gesamte Fahrzeug aufgrund eines Mangels ein wirtschaftlicher Totalschaden ist und ich mit einem neuem Fahrzeug ausgestattet werde, würde ich schon davon ausgehen wollen, dass für diesen "neuen"
Geschäftsvorfall auch eine neue Garantiezeit vereinbart wird. So mein Ansatz.
Der Verbraucher kann werder was für den Mangel am Gerät, noch für den Totalausfall, noch für den Erhalt eines Neu- bzw. Ersatzgerätes. Um einfach mal sachlich zu bleiben, selbst wenn das Ersatzgerät 5x besser ist wie das defekte.

Danke für Euer Feedback.
Mir ging es tatsächlich um das Problem, dass bei dieser Serie, wie tiermutter schon geschrieben hat , und um das es hier im Thread geht.

Und jetzt haben QNAP und ich ein Diskrepanz die es zu lösen gilt. Ich möchte gern für das Ersatzgerät eine neu beginnende Garantie von mind. 2 Jahren.
Derzeitiger Stand ist, dass ich für das Ersatzgerät die Restlaufzeit der Garantie für das defekte Gerät bekomme. Angenommen, es sind noch 2 Wochen Restlaufzeit, dann habe ich für das Ersatzgerät noch 2 Wochen Garantie.

Und da QNAP sehr darum bemüht ist, nur das Beste für den Kunden zu tun, bin ich damit nicht einverstanden und wir sind am Konditionen aushakeln.

Hallo zusammen,

mein NAS TVS-672N-i3-4G-EU hat es vergangene Woche, pünktlich am 01.09. erwischt.
Ist auch schon bei QNAP.

Ich brauche bitte Eure Meinung/Hilfe.
Folgendes Angebot ist heute von QNAP gekommen:

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von QNAP Support

Dear Frank,

This is QNAP RMA center in Germany.

We have already received your Nas TVS-672N-i3-4G-EU. Unfortunately, this model is currently out of stock.

Therefore, we would like to offer you another comparable Nas TVS-672XT-i3-4G-EU.

You don't need to pay any extra fee for this substitution because we consistently dedicate ourselves to provide a satisfactory service to every customer.

Would you like to accept this substitution?

If you have any further questions, please feel free to contact us.

Alles anzeigen

Kann mir jemand was zu dem Gerät sagen? Konkret, gibt es bei diesem Gerät keine Probleme, z.B. Hardware wie bei dem 672N? Oder Sonstiges?
Danke Euch.

ja wie geschrieben. Es gab die Ankündigung, via QFinder das für die Box ein Update zur Verfügung steht.
Der Support hat geschrieben:...das kann schon mal vorkommen.

Barungar ich stimmt Dir zu. Bin schon wieder Off-Topic, - ist es denn jetzt empfehlenswert QuFirewall zu nutzen?

Danke ersteinmal für die Hilfe
Helljumper da ist kein Update durchgeführt wurden. Die Box ist vor sich hingelaufen und heute Morgen war der Zugriff weg. Im QFinder habe ich die Information zum Update gesehen. Updates mache ich manuell.
Zum Thema "Massensterben", ein lachendes, ein weinendes Auge. Einerseits bin ich froh, andererseits hätte ich das Thema gern vom Tisch. Doch irgendwas ist ja immer

tiermutter Ich habe mich gewundert, da ich dergleichen nicht im Kopf habe. Es sei den es gibt systemseitig etwas, was noch ausgeschaltet werden kann. Wenn Barungar und du die QuFirewall meinen, die man App seitig erst installieren muss. Die habe ich nie gehabt.

Das Log zeigt auch nichts Aussergewöhliches, bis ich manuell ausgeschaltet habe.
Gut QVPN. Doch die Anwendung läuft seit 3 Jahren +. hmm, muss ja nicht alles verstehen. Heute schon gelernt, dass es sinnvoll ist seine Systemeinstellungen zu sichern. Geht das eigentlich automatisiert? Würde ich sehr gut finden.

Über QFinder SSH passiert nichts.

3s Reset hat geholfen. Danke
das nächste Mal Einstellungen sichern, dann tue ich mir leichter.

Was hat es mit der der QFirewall auf sich und kann ich dagegen was unternehmen?

Warum kann ich nicht in einem Beitrag antworten? Steht bestimmt was in den Foren-Regeln.
Habe ich richtig verstanden, dass es wohl nichts mit dem "Massensterben"-Fehler zu tun hat?

Ja. Stimmt auch.
QFinder findet das Gerät nicht. Erst wenn ich den Netzwerkstecker ziehe und wieder einstecke findet QFinder das Gerät und dann nur für ca. 3 Minuten, wie geschrieben. Danach findet die Software das Gerät nicht mehr.

Dann kann ich das Spiel wieder von vorn beginnen.
Zugriff auf die Box bekomme ich gar nicht.