Beiträge von schumaku

Das Feature wird nicht mehr unterstützt - das Risiko ist zu hoch.

-> https://forum.qnap.com/viewtopic.php?f=182&t=138370#p656061

Zitat von phoneo

Ich möchte weder meine "möglichst hacksicheren" Nas-Passworte für die Anmeldung am Desktop nutzen, noch die einfacheren Desktop Passworte fürs Nas.

Ja, ich benutze auch relativ komplexe, lange Passworte. Windows 10 bietet die wunderbare Funktion eines Login per PIN an ... als es noch opportun war, haben wir Fingerabdrucksensoren genutzt. Aber halt, hier kommen gleich die Aluhutkandidaten wieder. Ihr verwendet ja für jede Resource andere Passworte.

Und meine User brauchen Schreibzugriff auf die Freigaben - genau so wie sie es auch im Geschäft mit der Active Directory Domain haben, inkl. einem Single Sign On. Usability gewinnt. Das funktioniert übrigens durchgehend auch bei den grössten Microsoft Key Accounts - mit so einer geschätzten Viertelmillion Usern, 24*7 Produktion von Schokolade oder Kaffeekapseln.

Für alle Anderen - mir ist es egal wie schwer Ihr Euer NAS Leben - und das Eurer Benutzer - machen wollt.

Zitat von VaexX

Win+R -> gpedit.msc -> Computerkonfiguration ->´ Administrative Vorlagen -> Netzwerk -> LanMan-Arbeitsstation -> Unsichere Gastanmeldung aktivieren

Bitte nicht. Microsoft hat viele gute Gründe no-authenticated (eben den sogenannten Gastzugriff) auf dem Client zu deaktivieren.

When looking into the https://wiki.mikrotik.com/wiki/Manual:Interface/Bonding and your information about the CPU load I conclude the bonds are host bonds, and the Ethernet ports on your switch are not handled direct by a switch silicon. Appears the ports taking part in a bond are handled by the RouterOS as host ports, and there is some kind of (Linux) bonding active under the hood.

For example the Netgear R9000 does the very same - and I can get higher bandwidth on a single session than feasible with a single GbE between the 2*1GbE trunk and the 10 GbE SFP+, too.

It's a special case therefore - both your MikroTik and my R9000 are Linux bonding hosts - not "dumb" GbE switches.

Verzeihung ... aber ich war gerade im Englisch-Modus. Die zwei Trunks werden auf dem RouterOS konfiguriert, es wird da ein Trunk mittels Linux Bonding konfiguriert, welcher dann per Bridge mit den anderen Ports bzw. Trunks zu einem L2 Netwerk verbunden werden. Darum verhält sich der Router eben als Linux Host, und nicht wie ein normaler Ethernet Switch. Und von da her kommt auch die CPU-Last, welche Du weiter oben erwähnt hast.

Grüsse
-Kurt

Zitat von marisse

Natürlich geht das, dafür nutzt man den balanced-rr-Modus (Bond-Mode 0) und nicht 802.3ad (LACP). Damit wird auch eine einzelner Socket/Session über die Interfaces verteilt. Also eine einzelne Operation wie z.B. scp einer großen Datei gehen mit >1Gbit/s über die Leitung(en).

Das funktioniert wohl nur bei direkten Verbindungen zwischen Server und NAS.

Zitat von MonDieu

Hallo

Das Problem ist das sich das QNAP wie beschrieben selbst nicht mit GBit anmeldet sondern nur mit 100Mbs.

Lieber Gott .. woran hängt denn Dein TS-212 aktuell?

Zitat von MonDieu

Suche noch immer noch jemandem der das TS212 mit GBit wie Bild2 betreibt.

Wenn möglich an einem Switch kleiner/gleich 8 Ports.

"Jemand" hat (etwas weiter oben) diese Frage bereits beantwortet. 8-)

ZyXEL GS1900-24E (V2.30(AAHK.0)): 1 Gbps, MTU 9000
ZyXEL GS1900-48 (V2.30(AAHN.0)): 1 Gbps, MTU 9000

Noch einige mehr ... kurz mal vom Legacy-Rack zum Labor gepatcht:

TS-212 QTS 4.3.3.0404
Netgear GS908E (v1.0.0.3): 1 Gbps, MTU 9000
Netgear GS110EMX (v1.0.0.6, GbE port): 1 Gbps, MTU 9000
Netgear GS108PP: 1 Gbps, MTU 9000
Netgear GS324: 1 Gbps, MTU 9000
Netgear GS750E: 1 Gbps, MTU 9000
Netgear Nighthawk S8000 (GS808E, v1.0.2.3): 1 Gbps, MTU 9000
Netgear Nighthawk SX10 (GS810EMX, v1.0.0.1, GbE port): 1 Gbps, MTU 9000
Netgear Nighthawk X10 (R9000, 1.0.3.6, GbE port): 1 Gbps, MTU 9000
Netgear Insight GC110 (v1.0.2.8): 1 Gbps, MTU 9000
Netgear Insight GC510PP (v1.0.2.8): 1 Gbps, MTU 9000
Netgear MS510TX (v6.7.0.27, GbE port): 1 Gbps, MTU 9000
Netgear MS510TX (v6.7.0.27, 2.5 GbE port): 1 Gbps, MTU 9000
Netgear MS510TX (v6.7.0.27, 5 GbE port): 1 Gbps, MTU 9000

Es dürfte also leichter sein einen Switch (oder einen Router mit eingebautem Switch) zu finden als eben diese (ganz wenigen) welche aus was auch immer für Gründen mit den Legacy-Marvell ARM NAS (TS-x10, TS-x12, ...) nicht GbE mögen. Weder QNAP noch Marvell wird daran etwas ändern. Also auf zum Baumarkt, dem Discounter, ibäh, ... für einige wenige Euros gibt es fünf- und acht-Port GbE Switches. Die oben getesteten sind etwas teurer oder grösser.

Spätestes Ende Dezember 2020 haben die Marvell Kirkwood NAS dann wohl ausgedient - dann gibt es keine Security-Updates mehr.

Ein "echtes" TS-212 (QTS 4.3.3.0404) an einem ZyXEL GS1900-48 (v2.30(AAHN.0)C0).

Switch wie NAS zeigen eine GbE-Verbindung an, der Durchsatz ist massiv höher als ~11.8 ... 12.2 MB/s (was auf eine Fast Ethernet Verbindung hinweisen würde)

[~] # ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 8
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbag
Wake-on: d
Link detected: yes

Eben von hier aus geprüft - das QNAPclup.eu Store App Repository liess sich diese Minuten (wie bisher) von x-beliebigen x86_64 Systemen aus Einbinden und Abfragen, ebenso auch von den ARM basierenden TS-x31 , TS-x31+ (AL, QTS 4.3.4.0435), TAS-x68 (QTS 4.3.3.0404) und TS-x12/TS-x19 (KW, QTS 4.3.3.0404). TS-x10 Systeme (älteres QTS 4.2.x) hab ich leider keine.

Über die Neujahrestage habe ich aber dasselbe Problem festgestellt und bei QNAP einen Bugreport erstellt (MantisBT ID 28105) - die Information könnte nützlich sein wenn Ihr ggf. ebenfalls mit dem Support Kontakt habt. Bitte diesen Thread hier ggf. auch weiter führen.

Die einzigen Variable ist die Art der Verbindung: Direkt auf die private bzw. öffentliche IP Adresse mit Port-Weiterleitung (dan erfolgt die Verbindung praktisch direkt*) _oder_ falls CloudLink verwendet wird (so eine Art VPN über einen Cloud Service, welcher von QNAP zur Verfügung gestellt wird hergestellt).

*1) Im Fall der Mobile-Provider sind vielfach noch eine spezielle Art von Proxies in der Datenverbindung drin.
*2) Bei irgend einer anderen Internet-Verbindung (Wi-Fi, Firma, usw.) kann ein Proxy, oder Proxy-ähnliches System im Datenpfad mit drin sein.

Das alles ist nicht speziell nur auf die File Station zutreffend, sondern auch den QTS Desktop, andere QTS Apps, QNAP Mobile Apps.

War eigentlich er Ansicht das das ein temporäres Problem war (und nur auf ARM Systeme beschränkt) - heute Vormittag hat es mit Marvell Kirkwood, Annapurna Labs und den TAS/TS-x28 wieder funktioniert. Derzeit unterwegs beim Eishockey 8-)

Zitat von kasimodo

"automatische Updates" - du bist aber mutig!!! das würde ich generell deaktivieren und neue Updates erst einspielen wenn sie schon länger auf dem Markt sind!

Wenn man - auf eigens Risiko - Kernelmodule usw. selber verbaut ... ja. Da hilft nur Prüfen, Testen, ...

In jedem Fall ist es ein Spiel mit dem Feuer die Aktualisierungen nicht zeitgerecht einzuspielen. Pauschal deaktivieren ist ein schlechter Rat.

Es gibt einige "Exoten" welche ganz klar Einschränkungen haben - QNAP wollte diese schon länger stehen lassen, Marvell Kirkwood wo es beim Mitbewerber schon seit längerem nix mehr Neues gibt, und nur ein Uralt-Kernel vorliegt). Der Preis war, dass das "Drumherum" eben so stehen bleiben musse. Sonst hätten wir schon seit zwei Jahren Ende Gelände gehabt. Und ja, Exoten sind auch TAS, TS-x28, TS-x31.

Hallo @kasimodo

Das war natürlich mehr zur Erheiterung gedacht. Du hast mit deinem einleitenden Post natürlich vollkommen Recht. Sprache beiseite, QNAP mag das nicht wirklich hören, leider.

Die Frage bezüglich den Root-Zertifikaten beantworte ich Dir gerne: QNAP sieht ssh nur für die Fehlersuche vor, für admin und zusätzlich berechtigte Benutzer (die zugleich Mitglied der administrators Gruppe sein müssen), und das ausschliesslich mit password-auth. Das steht in den Spezifikationen, und das ist so implementiert.

So lange es kein rooted-environment für Benutzer gibt (sei es für ssh oder auch sftp) macht das alles auch nur wenig Sinn. Und wie soll QNAP Support machen wenn der Benutzer seinen SSH verbockt?

Im Englischen Windows -> Control Panel -> Credentials Manager .. Windows Login

In Microsoft-Deutsch -> Systemsteuerung-> Anmeldeinformationsverwaltung ... Windows-Anmeldeinformationen

Es braucht m.n.m.E. ausschlieslich solche Informationen in English.

Zitat von Schmerzspender2000

Nehmen wir folgends verrücktesSzenario an:
Habe ich so gemacht. USer auf der NAS und Win identisch!

Soweit nichts verrücktes ...

Zitat von Schmerzspender2000

Also über den Explorer auf die NAS Fehler bei der Anmeldung.

Erstelle ich ein Netzlaufwerk auf eien Ornder dann klappt es ohne dass ich einen Usernamen oder Passwort eingeben muss.... macht das Sinn?

Ja, ich denke schon. Die Vermutung ist naheliegend dass in dem Windows Benutzerprofil noch ungültige Credentials für das NAS abgespeichert sind.

Eines Tages wird jeder User verstehen (müssen) dass die Idee mit dem "Login" auf Shares schlicht Müll ist. Warum richten sich die Leute nicht die selben Benutzernamen und Passworte ein, welch auf dem Windows Desktop benutzt werden, und vergeben die Rechte auf den Shares entsprechend? Dann fraget das NAS bzw. der Windows Client nie mehr nach Benutzername und Passwort - ausser es ist etwas falsch konfiguriert. Single Sign On heisst das dann - und ohne dass Eure Benutzernamen und Passworte auf dem Credentials Manager gespeichert werden. Und ohne dass der Credentials Manager da seine Finger im Spiel hat und Dinge tut welche man im Supportfall nur schwer nachvollziehen kann.

Völlig rätselhaft wie QTS auf die Idee kam die (ebenfalls verschlüsselte) Freigabe auf einem verschlüsselten Volumen anzulegen. Von sich aus sicher nicht....

Wenn der Shared Folder auf /share/CE_Cachedev1_Data/ zeigt so handelt es sich um ein verschlüsseltes Volumen - nicht einen verschlüsselten Folder/Freigabe auf einem normalen Volumen (das wär dann z.B. /share/Cachedev1_Data/).

Soweit mir bekannt ist, kann man ein Volumen mit Daten nicht einfach verschlüsseln - nur eine Freigabe kann nachträglich verschlüsselt (oder auch entschlüsselt) werden.

Schau mal im Storage Manager nach... nicht bei den Freigaben.

Zitat von Jagi

Erschreckend. Bei mir ist NoScript ruhig und zeigt nix an.

Für die die auch nichts sehen - nach der Installation hat NoScript alle Ausnahmen die der OP so nicht liebt aktiviert. Auch so (alles manuell aktiviert) ... ich sehe auch nichts.

Gut verstehe ich von IT nichts. Ausser das sich da viele Gestalten tummeln. Auch Kollegen mit Aluhüten.

Ich habe nicht gesagt was da Richtig oder Falsch ist, sondern erklärt warum das gemacht wird - und auch nicht um eine Beurteilung gefragt. Dieser EU Schabernack wurde aus ganz anderen Gründen formuliert, und nicht wegen rein technisch bedingten Lösung.

Es geht in keinem Moment um eingehende Verbindungen - sondern die Erreichbarkeit des Internet und je nach Einstellung die automatische Konfiguration des aktiven Default Gateways auf verschiedenen Interfaces/LAGs/Virtual Switches. Klar, die Lösungen welche QNAP implementiert hat hilft dabei auch. Offenbar eine weitere vorgefasste Meinung in dieser Diskussion, die offenbar nicht auszumerzen ist.

Die Erreichbarkeit eines DNS Servers hilft hier wenig - der kann irgendwo im eigenen, im grösseren eigenen, auf dem Router, beim ISP, usw. sein - der Test hilft entweder nichts, oder nur wenig. Zugegeben, wenn Peerings weg sind, BGP4 Sessions zwischen den ISP down sind, ... kann das NAS auch nur wenig ausrichten.

Aber Lesen und Verstehen ist eben schwierig. Lärm machen und mit Klagen drohen passt da irgendwie. Genau der selbe Unfug der in der heutigen Zeit mit sogenannten Unworten gemacht wird, kuck mal her http://www.dubler.net/ - Stichwort: "Mit Schokolade überzogene Schaumspeise mit Migrationshintergrund".