ständig diese "Kaputte Pipe"-Meldungen
Broken Pipe ist bei mir immer eine Folge einer Netzwerkunterbrechung oder eines längeren Timeouts. Daher würde ich einen Blick auf die Stabilität der Verbindung werfen.
Beiträge von Anthracite
-
-
habe die APP auch deinstalliert und neu installiert..
Wenn ich nach einem Update Probleme mit der VS habe, reicht in der Regel im App-Center einmal stoppen und neu starten. Eine Deinstallation war nie nötig.
Jetzt ist es natürlich zu spät, und ob Stop/Start bei deinem Problem hilfreich gewesen wäre, weiß ich nicht.
-
Da keiner hier den Prozess kennt und da du ecodms als spezielle App laufen hast, denke ich mal, dass der Prozess damit zusammenhängt. Stoppe mal ecodms (im App-Center, nur stoppen, nicht deinstallieren) und schau, ob die Prozesse dann weg sind.
-
Kein Warum.
Die Aussage von florit ist falsch.
Wenn alle Teilnehmer in einem Subnetz eine manuelle IP-Adresse haben und die Netzwerkmaske (und im Prinzip auch das Gateway, hier aber nicht, da es keines gibt) manuell eingetragen ist, dann ist kein DHCP-Server nötig.
-
Bringt mir (momentan) nichts
Wenn der Fehler wirklich in den Adaptereinstellungen der 10GbE-Karte liegen sollte, wird es dir auch langfristig nichts bringen
-
und für schmale 99 Taler ein Schnapper
Vermutlich ohne MwSt und ohne Service. Wenn man beides drauf rechnet, landet man wieder bei Preisen nahe den günstigsten Angeboten hier.
"chinesischen Perlen"
Es ist halt ein Glücksspiel. Man kann Glück dauerhaft haben, man kann eine Zeit lang Glück haben, bis das Gerät doch Ärger macht, man kann ab sofort Pech haben. Ich habe schon zu viel Chinaschrott (allgemein, nicht auf Switches bezogen) gesehen, als dass ich No-Name-Billigprodukte empfehlen könnte.
-
Die Logik beim Zugriff auf nfs ist, dass der nfs-Server die Dateirechte übernimmt und die Zuordnung über die User-ID (ab nfs 4.0 alternativ Usernamen) macht. Wenn dein Linux-User mit der UID 1000 eine Datei auf dem eingebundenen nfs-Laufwerk anlegt, dann gehört diese Datei auch auf dem NAS dem User mit der ID 1000.
Arbeitest du hingegen mit dem User root (auch über sudo), welcher die UID 0 hat, dann ist auch auf dem NAS die neue Datei der UID 0 zugeordnet.
Dies Ganze geschieht ohne weitere Authentifizierung. Es reicht der Login bzw. das gestattete sudo-Kommando auf dem Linux-Rechner. Eine Anmeldung auf dem NAS ist nicht nötig. Wenn alle Rechner im Netzwerk ebenfalls unter deiner administrativen Kontrolle sind (wie bei einem Firmennetzwerk), und du festlegen kannst, welcher Benutzer wo überhaupt sudo ausführen darf, ist alles in Butter.
Gibt es aber einen Rechner im Netzwerk, der nicht unter deiner Kontrolle steht, wo der Benutzer selbst das root-Passwort kennt, dann kann er nach Belieben auf Dateien auf der nfs-Freigabe zugreifen, auch solche, die eigentlich nur root gehören, und zwar ohne sich auf dem NAS anzumelden.
Dieses Verhalten kann unerwünscht sein. Daher kann mit den obigen Optionen entweder dem Root-User oder allen Usern eine andere UID auf dem NAS zugewiesen werden.
Bei SMB (CIFS) ist das übrigens anders. Die Zugriffsrechte der Dateien auf dem NAS spielen keine Rolle, und die Rechtevergabe erfolgt über die Anmeldung am NAS.
Greift ein Rechner auf eine Freigabe per SMB zu, ein anderer auf dieselbe Freigabe per nfs, führt das schnell zu Problemen. In einem solchen Szenario sollte auch Linux die Freigabe besser per SMB (CIFS) einbinden.
Hab's jetzt mal mit "Alle Benutzer zuordnen" probiert und hab festgestellt, dass ein als root gesarteter rsync -rv local /nas/Pfad, den man abbricht und wieder neu startet, alle Dateien von frischem komplett neu überträgt.
Du hast die UID-Zuordnung geändert, und deswegen müssen alle Dateien mit anderes UID und GID neu angelegt werden. Aus Sicht vno rsync sind es deswegen nicht dieselben Dateien.
-
Sowohl auf dem NAS als auch auf dem PC brauchen beide Ports jeweils eine eigene IP-Adresse. Du hast dann auf beiden Geräten jeweils zwei IP-Adressen.
Für die Direktverbindung nimmst du besser ein eigenes Subnetz, also nicht 192.168.10.x, sondern z. B. 192.168.20.x. Das gibt weniger Probleme beim Routing. Da es in dem Subnetz 192.168.20.x keinen DHCP-Server gibt, musst du die beiden Adressen manuell vergeben, Gateway-Eintrag bleibt leer.
Ob du dann über 10GbE oder über Gigabit auf das NAS zugreift, legst du durch die Wahl der Adresse fest, z. B. nimmst du bei "Netzlaufwerk verbinden" die 192.168.20.x-Adresse des NAS.
Die Alternative dazu ist die Anschaffung eines 10GbE-Switches (z. B. Mikrotik CRS305, der ist relativ günstig).
-
komme ich immer „nur“ auf 800 bis 850 MB/s
Einiges hängt auch davon ab, wie du misst.
Wenn du z. B. große Dateien vom NAS auf deinen PC kopierst und die Zeit misst, dann hast du in der Zeit nicht nur die Zeit zum Lesen und transferieren vom NAS, sondern auch die Zeit zum Schreiben auf die SSD des PCs. Letzteres verfälscht dein Ergebnis. Dedizierte Geschwindigkeitstestprogramme vermeiden den Schreib- und Lesezugriff auf dem PC.
würde mich interessieren ob schon jemand eine Dual-port (SFP+) 10Gb reingesteckt und gemessen hat
Ich habe eine Dual-Port-Karte mit sfp+ im NAS, aber nur deshalb, weil ich die Karte gebraucht gekauft habe (HP/Emulex), und der Preis war derselbe wie für Single-Port (habe 35 Euro bezahlt). Auch im PC ist eine Dual-Port-Karte, nur kann ich die Messung trotzdem nicht vornehmen, weil das NAS im Keller steht, und zwischen Keller und erstem Stock liegt nur ein Kabel (Glasfaser immerhin, begrenzt mich dennoch auf 10GbE).
-
Ziehen und Wiedereinstecken einer Platte kann dazu führen, dass das Raid sich erneut synchronisieren möchte. Wenn du während dieser erneuten Synchronisation eine weitere Platte ziehst, hast du dein Raid möglicherweise zerschossen. Daher vor dem Ziehen einer Platte schauen, dass kein Synchronisationsjob auf dem Raid läuft.
Was ich jedoch machen würde:
- Warten, bis Synchro fertig.
- NAS runterfahren und ausschalten
- Nacheinander alle Platten einmal rausnehmen und Schrauben nachziehen, so dass sie fest in der Halterung sitzen, und Platte wieder einstecken.
- Raid einschalten und wieder hochfahren.
Wenn du im ausgeschalteten Zustand eine Platte entnimmst und wieder einsteckst, ohne sie zu wechseln oder den Inhalt zu ändern, kriegt das NAS hiervon nichts mit. Dann geht die Aktion schneller.
-
Ok, es wird hoffentlich ein paar Monate halten
Oh Mann, habt ihr aber wenig Vertrauen in die Haltbarkeit moderner Festplatten. Ein Raid 6 bei nur vier Festplatten ist mMn. absolut oversized. Ja, es kann passieren, dass innerhalb kurzer Zeit zwei Platten ausfallen, aber solche Defekte sind viel zu selten im Vergleich zu Fällen, die auch ein Raid 5 abfängt (eine Platte defekt, das kommt schon eher mal vor) und solchen, gegen die auch ein Raid 6 nicht hilft (Blitzeinschlag, Schadsoftware, eigene Dummheit).
=> Belass es bei einem Raid 5, das ist perfekt. Das ist (bei vier Schächten) der beste Kompromiss zwischen Sicherheit und Aufwand (Kosten).
-
Die Antwort von carsten_h ist nur teilweise korrekt.
Wenn dein Player (hier infuse) per SMB auf die Freigabe des NAS (oder eines anderen Speichers) zugreift, dann ist es kein Streaming (wie Carsten schreibt), da der Player Vollzugriff auf die Datei hat und selbst bestimmt, wann, so und wie schnell die Video- und Musikdaten gelesen und abgespielt werden.
Greift der Player hingegen per DLNA auf das NAS zu, dann wird dort ein DLNA-Server gebraucht (bei Qnap z. B. Multimedia-Konsole mit Mediastreaming-Addon), welcher die Datei liest und per Streaming verteilt. Der Player gibt die Video- und Musikdaten so aus, wie sie ankommen, hat aber kaum weitere Kontrolle darüber.
Infuse kann, wenn ich das recht gesehen habe, beides.
-
sonst halt auf default 1514 setzen
Ja, genau, 1500 ist kein Jumbo.
-
Ausfallsicherheit. Fällt eine HDD aus, geht der Betrieb ungestört weiter und die defekte Disk kann ersetzt werden.
Und nicht zu vergessen, da im Privatbereich vielleicht das Wichtigste: Der Ersatz einer defekten Platte ist mit minimalem Aufwand machbar. Alte Platte raus, neue Platte rein, den Rest macht das NAS. Ohne Raid müsste man erst auf der neuen Platte Volumen und Partitionen anlegen, dann das letzte hoffentlich komplette Backup einspielen und anschließend möglicherweise noch ein paar fehlende Konfigurationen (z. B. Freigaben, Rechte) nachziehen.
-
Ich würde dann 9000 & 9014 nehmen und einen Geschwindigkeitstest (SMB-Geschwindigkeit, kein iperf3) machen, ob es funktioniert, d. h. ob es etwas bringt. Wenn der Geschwindigkeitsvorteil nur minimal ist, kann man die Jumboframes wieder abschalten - ganz vereinzelt machen sie dann doch mal Probleme (bei mir trifft es einen VPN-Zugang, ziemlich altes Programm, der dann nicht geht).
-
Zwei Konfigurationsfehler hast du:
172.0.1.10 ist eine öffentliche Adresse und darf nicht verwendet werden. Der privat nutzbare Bereich erstreckt sich von 172.16.0.0 bis 172.31.255.255.
Die Thunderbolt-Verbindung hat keinen Router, und dort darf auch keiner angegeben sein. Lass das Feld "Router" bei der Verbindung leer.
Und noch ein Tipp: Im 172-er Bereich darf die Netzwerkmaske 255.255.0.0 verwendet werden, aber je größer du den privaten Bereich definierst, desto eher riskierst du, z. B. in Firmennetzen (Notebook mobil eingesetzt beim Kunden) o. Ä. einen Adresskonflikt. Wenn du keinen besonderen Grund für die Nutzung eines großen Bereichs hast, dann nimm 255.255.255.0 auch im 17er Bereich.
Edit:
Die TB4 Bridge sollte auf automatisch stehen.
Eher nicht, es sei denn, das NAS hat extra dafür einen DHCP-Server.
-
[Zu Was funktioniert nicht mehr?] Na du bist ja zuversichtlich
Das ist doch die wichtigste Frage. Wenn eine Funktion, die ich benutze, plötzlich nicht mehr geht, darf ich kein Update machen. Wenn neu hinzugekommene Funktionen noch nicht tun, was sie sollen, ist mir das relativ egal. Wobei mir nicht klar ist, was denn an der Version wirklich neu ist.
Ich bezweifle allerdings, dass die VS 4 aus dem Betastadium raus ist
Sie wird mir offiziell als normales Update angeboten. Also kein Beta.
obwohl die nur schmalbrüstig ausgestattet waren, sind die 8GB RAM wohl dennoch zu wenig
Die VMs waren der Grund, mein NAS von 16GB auf 48GB zu erweitern. Einmal läuft Windows Server für Kundenprojekte, einmal läuft Ubuntu als Datenbankserver mit MariaDB und MSSQL - für letztere VM waren zugewiesene 6GB knapp.
-
Seit gestern gibt es mit der Virtualization Station 4.0.0.239 eine 4er-Version, die nicht mehr Beta ist.
Alles anzeigenVirtualization Station 4.0.0.239
( 2024/04/17 )
[Important Notes]
- QNAP does not support downgrading Virtualization Station 4.0 to an earlier version to avoid unpredictable application issues.- VMs backed up or exported from Virtualization Station 4.0 are only compatible on devices using Virtualization Station 4.0 and later versions.
- Virtualization Station 4 deprecates independent HTTP/HTTPS ports for enhanced security and logins. Access after update requires using the system port. To log in to the application after updating to version 4, you must use the system port.
- In accordance with Microsoft's deprecation of specific Windows® VM image download URLs, all features related their deployment have been disabled.
- Notification rules configured for Virtualization Station are reset when you update to version 4. Make sure you recreate the notification rules to continue receiving notifications related to application events.
- Virtualization Station 4 has ended support for vQTS. Make sure that you back up all the relevant data and files before updating the application to version 4.
- QTS user's Windows virtual machine might in the status of suspended when upgraded from Version 3.6.52 to Version 4.0.0.239.
- To ensure Virtualization Station 4.0 works properly with QNAP operating systems 5.2.x, update Virtualization Station to version 4.0.0.239.
[New Features]
- VMs now retain their previous state across application updates, eliminating the need for post-update reconfiguration.
- During application update, if the system detects an existing dataset (configuration), a confirmation dialog prompts users to choose between data reinitialization and data migration.
[Fixed Issues]- Resolved an issue where Virtualization Station background processes would not terminate correctly when the application is disabled.
- Addressed a connection issue that prevented virtual machines from establishing a connection using a SPICE client.
- Addressed a compatibility issue that could occur between Virtualization Station and QuWAN vRouter following device reboots.
- Resolved an issue that prevented Virtualization Station from displaying ISO files.
[Compatibility]- Virtualization Station 4.0.0.239 is only compatible with QTS 5.1.x and QuTS hero h5.1.x and later versions.
- The following applications are compatible with Virtualization Station 4. Make sure that you update these applications to the following versions (or later versions) before updating to Virtualization Station 4:
- QuWAN vRouter 1.1.8
- VM Installer 1.2.4
Ich trau mich noch nicht.
Wer hat diese 4er Version schon im Einsatz?
Was ist neu?
Was funktioniert nicht mehr?
-
zum spielen sollte es erstmal gehen ... klar ist`n Billigheimer
So ein No-Name-Switch ist halt ein Glücksspiel. Wenn du den Switch innerhalb von zwei Wochen zurückgeben kannst, ohne ihn nach China senden zu müssen (ins Kleingedruckte schauen!), kannst du es riskieren. Bei späterem Defekt droht dir ja kein Produtkionsausfall. Ich würde innerhalb der zwei Wochen mit iperf3 testen, ob die Ports die versprochene Geschwindigkeit bringen.
Falls du aber vorhast, beide 10GbE-Ports mit GBase-T über rj45 zu verbinden (dein Mac kann nichts anderes), dann ist der Switch teurer als der von Qnap ein paar Beiträge weiter unten! Die sfp+ Ports sind dann gut und preiswerter, wenn auch die Gegenstellen sfp+ Ports haben und eine Verbindung über DAC-Kabel oder LWL vorgenommen wird.
In der Preisklasse sind wir dann beinahe schon beim 10Gbit-QNAP-Switch , was ist denn von dem zu halten?
Ich gehöre zu denjenigen, die mit Qnap-Switchen schon Ärger hatten, dennoch würde ich den Qnap-Switch gegenüber dem Netgear vorziehen. Dein Mac hat eh' schon 10GbE, und vielleicht wirst du irgendwann dein NAS auf 10GbE aufrüsten, dann ist der Switch schon vorbereitet. (Mein Problem mit Qnap war eine Inkompatibilität mit einem alten 10GbE-Thunderbolt-Adapter. Wenn du kein Gerät hast, das inkompatibel ist, wirst du den Nachteil nie bemerken.)
Die Grenzen dieses Switches:
- Nur zwei GbE-Ports. Stört nicht, wenn du nie mehr als einen PC/Mac und ein NAS damit betrieben willst.
- Keine Management-Funktionen. Wenn du nicht vor hast, mit VLANs zu spielen oder ein Gästenetzwerk an einem LAN-Port zur Verfügung zu stellen, dann ist dies im Heimnetz idR. kein Problem.
Positiv zu vermerken ist, dass er lüfterlos ist.
-
Auf den Port reagiert nur das laufende Plex Programm auf dem NAS, nicht das NAS selber!
Gefahr besteht, wenn Plex einen Fehler hat, der zum Einbruch auf das NAS verwendet werden kann.
Da könnte ich genauso sagen: "Bis zum nächsten/ersten Exploit der VPN Software"
Das ist genauso unsicher.
Im Prinzip ist das richtig, aber VPN (und ssh) dürften "etwas" besser auf maximale Sicherheit konzipiert, abgehärtet und getestet sein.
Wenn man einen Port für eine Anwendung freigibt, sollte man abschätzen
- Wie gut ist die Anwendung auf maximale Sicherheit konzipiert?
- Wie gut wird die Anwendung in Bezug auf Angriffe getestet?
- Wie oft wird die Anwendung für diesen Zweck eingesetzt (bedeutet Tests im praktischen Einsatz)
- Was muss ich selbst für einen sicheren Betrieb tun (Updates, Konfiguration)?
- Wie groß ist die Angriffsfläche?
Diese Abschätzung spricht für die Portfreigabe von VPN (und ssh, wenn eine sichere Konfiguration vorliegt) und gegen die Portfreigabe von Plex.
