Beiträge von sagusch

da, denke ich, alles gesagt wurde, schließe ich diese gesprächsrunde.

der themenersteller dankt erstmal allen beitragserstellern für ihre bemühungen.

die quintessenz für mich: will ich, dass grundsätzlich anmeldungen notiert werden (ja!), dann habe ich in kauf zu nehmen, dass alle, auch fehlgeschlagene, aufgeführt werden (is halt so).

nun hat so gut wie jeder nutzer im heimnetz auch ein konto auf dem nas, aus sicherheitsgründen allerdings mit anderslautendem namen als der seines benutzerkontos unter windows. aus diesem umstand resultierten ja die unzähligen anmeldewarnungen.

als umgehung dieses unerwünschten sachverhalts habe ich für alle windows-nutzer nun auch nas-konten mit deren windows-nutzernamen angelegt. diesen nutzerkonten sind sämtliche zugriffsberechtigungen auf jedweden freigabeordner entzogen, ebenso alle anwendungsberechtigungen, bis auf die fürs microsoft-netzwerk. diese nutzer können nun ihre nas-anmeldung (kennwort) an ihre windows-anmeldung angleichen.

auf diese weise wird beim öffnen des windows-explorers zwar die (erfolgreiche) anmeldung im nas-protokoll vermerkt, aber nicht in der oft ausufernden menge wie vormals bei den login-fail-einträgen.

sicher eher eine kosmetische maßnahme, die aber auch der überschaubarkeit dient, wenn recherche- oder analyse-aufgaben in den ereignisprotokollen anstehen ...

Zitat von RedDiabolo

Was meinst du mit "ohne SAMBA-Unterstützung stillzulegen"?

dateidienst für windows-netzwerk im nas deaktivieren

ich dachte halt, man könnte das nas vlt veranlassen, anmeldeversuche übers windows-netzwerk von ihm unbekannten nutzern zu "ignorieren" -- ohne gleich den dateiübertragungsdienst komplett abzuschalten ...

auf dem nas ist der windows-dateidienst aktiviert (gewollt). im lokalen netz gibt es rechner mit benutzerkonten, für die es auf dem nas keine entsprechung gibt. öffnet einer dieser nutzer den windows-explorer bzw einen dateifinder (öffnen- und speichern-dialoge), registriert das nas gleich mehrere (30-40) fehlgeschlagene anmeldeversuche (login fail), namentlich dieses (windows-)nutzers, der ja auf dem nas gar nicht eingerichtet ist. mit jedem weiteren geöffneten dateimanager wiederholt sich das; die systemverbindungsprotokolle werden gewissermaßen geflutet mit diesen "login fail"-einträgen.

gibt es eine möglichkeit, diese dem nas eigentlich nicht bekannten netzwerknutzer von der erfassung auszuschließen (ohne die samba-unterstützung grundsätzlich stillzulegen)?

kann ich wohl mal dicht machen ...

nachdem ich, wie von crazyhorse angeregt, eine ungesicherte verbindung hergestellt habe, wurde das server-portal geladen. nach einrichtung des plex-benutzerkontos und abschluss der einstellarbeiten wird dann eine verschlüsselte verbindung ermöglicht. der eingerichtete server ist in der lage, hevc-material wie gewünscht übers internet anzuliefern.

danke also für alle weiterführenden ratschläge in dieser hinsicht.

von plex werde ich dann doch keinen gebrauch machen, da, was mir vorab nicht klar war, ich aufgefordert bin, ein konto zu eröffnen, ich aber grundsätzlich abhängigkeiten von fremden portalen bei der nutzung eigener daten vermeiden möchte. desweiteren sind die nas-nutzer, wenn ich ihnen den zugriff auf die plex-mediathek vom nas aus ermöglichen will, dort wohl mit allen administrativen rechten ausgestattet. das daher notwendige anlegen dieser benutzer auf dem plex-server ist jedoch kostenpflichtig. letztendlich finde ich auch nicht zufriedenstellend, in welcher weise die dateinamen beim einlesen in die mediathek kompromittiert werden (das kriegt die video station wesentlich besser hin).

bleibt die hoffnung, dass sich vlt doch noch andere werkzeuge ohne die genannten einschränkungen finden oder dass qnap seine bordeigenen konverter "hevc-fähig" macht ...

ich betreibe unsere kleine wolke in erster linie als datei-aufbewahrung (sicherung und archivierung) und fröne dabei einem gewissen minimalismus. dreh- und angelpunkt ist die file station; alles, was nicht unbedingt nötig oder sinnvoll ist, wird nicht installiert bzw runtergeschmissen. auf diese weise erfüllt das nas prima seinen hauptzweck: dateiablage UND film-, bild, ton-bibliothek, von überallher mit verschiedenen clients erreich- und nutzbar. mehr als die file station und ggf qfile, qvideo usw ist/war dazu nicht nötig. und solange noch der vlc player als abspieler herangezogen werden konnte, gelang auch das abrufen (einschl echtzeit-kodierung) von hevc-videos. mit dem wegfall dieser möglichkeit ist hevc zu einer art i-tüpfelchen geworden, das uns jetzt fehlt. mehr will ich eigentlich nicht. das mit plex kommt mir da ein bisschen so vor wie das mit den kanonen und spatzen ...

danke aber für den ratschlag; lt plex-liste schafft unser datenhüter bis zu hd 1080p (bei verträglichen bitraten). bin's nun auch angegangen (vlt kann ich mich ja doch damit anfreunden). leider bin ich erstmal gescheitert, gleich bei der inbetriebnahme. will ich plex ausführen, öffnet sich ein neuer browser-tab unter der adresse

https://<nas-name>:32400 mit der meldung

"gesicherte verbindung fehlgeschlagen / verbindung zu ...:32400 wurde unterbrochen, während seite geladen wurde".

da steh ich nun. kann mir jemand sagen, wie's weitergehen könnte?

und gibt es vlt doch noch "sparsamere" lösungsmöglichkeiten?

hab mich, ehrlich gesagt, mit kodi & co noch nicht beschäftigt. aber geht's dabei nicht um das lokale netz, in dem sich beide, server und client, befinden? wir möchten, ich sag mal, in timbuktu einen film angucken, der in hintertupfingen in der nas-videothek liegt ...

tachchen

als wesentlicher zweck der spontantranskodierung wird ja vor allem die möglichkeit genannt, damit auf die leistungsfähigkeit des clients bzw der internetverbindung einzugehen. für uns besteht jedoch der größte gewinn darin, damit nun, statt nur mp4, ebenso andere videoformate (ts, mpg ...) abrufen zu können.

was die nutzung der spontantranskodierung auch durch nutzer ohne adminrechte betrifft, so hat uns ja warpcam entscheidend auf die sprünge geholfen.

leider mussten wir feststellen, dass bei hevc/h.265-kodierten videos die spontantranskodierung an ihre grenzen stößt. weitergeholfen hatte uns dann die möglichkeit, vlc als abspieler zu verwenden. damit ließen sich solche videos unter entsprechenden voraussetzungen (anschluss-bandbreite, client-leistung) sauber abspielen. wurde dabei statt der filestation die videostation genutzt, war auf diesem weg (mit vlc) sogar eine echtzeit-transkodierung drin.

mit der abschaffung von qvhelper (warum eigentlich?) ist jetzt auch der vlc-player-kontext geschichte -- sehr schade.

meine frage: kennt jemand vlt mittel und wege (abgesehen von einem vorhergehenden, sehr aufwendigen, export nach mp4), einen stream von hevc-material von entfernten geräten aus auf dem nas abzurufen?

gruß

sagusch

leider hat mein frommer wunsch nach beendigung deiner pechsträhne nichts gebracht, nescafegold; allzumal es wohl überhaupt nichts mit pech zu tun hat.

wie crazyhorse möchte ich mittlerweile den fokus auch nicht mehr auf "disk 8" als ursächliche fehlerquelle legen, sondern auf "schacht 8", also auf die schnittstelle zw platte und nas und damit auf alles, was dahinter halt so kommt (hard wie soft, platinen wie firmware). und damit läge der ball bei qnap und nicht bei wd ...

nescafegold, aus deinen beiden letzten protokollauszügen geht hervor, dass "hot-removing" jeweils bei einer rückkehr aus dem ruhemodus erfolgte. war das auch beim ersten mal der fall? dann kann dieser sachverhalt ja auch im sinne von crazyhorse als eine art konstante gesehen und als verursacher in betracht gezogen werden.

nun ist das aushängen der festplatte (durch was auch immer ausgelöst) das eine. das andere, mindestens genauso gravierende, sind doch die offensichtlich dabei in mitleidenschaft gezogenen festplatten (was sich dr_mike nicht vorstellen kann). sehe ich es richtig, dass du die austauschplatten jeweils vor dem anschließen einem test unterzogen hast, der immer ohne befund endete, und dann vor der rücksendung an wd wieder überprüft und dabei jedesmal sektorenfehler festgestellt hast? das besagt doch, dass die platten mit dem "hot-removing" nachteilig verändert wurden.

eigentlich kann hier nur noch qnap helfen oder gibt es nas-betreiber, die solches oder ähnliches erlebt haben und vlt sogar lösen konnten?

ohne den geringsten hinweis auf das warum auszugeben? nur lapidar: removed und disconnected?

wenn es sich denn im vorliegenden fall so verhielte, hieße das für nescafegold, dass mit einer auch nach dem rebuild noch kerngesunden platte der fall erstmal gelöst wäre ...

der von nescafegold beschriebene ablauf sieht doch so aus:

• neue, offensichtlich gesunde ("inter check bestanden") festplatte als austauschplatte von nas akzeptiert, wiederaufbau des raid beginnt
• wird ohne beanstandung abgeschlossen
• auf dem raid wird gearbeitet (kopiervorgänge); keine beanstandungen währenddessen; nas wird in ruhezustand versetzt
• nach erneuter inbetriebnahme wird die festplatte als im laufenden betrieb ausgeworfen gemeldet, mit dem folgerichtigen (!) hinweis, dass der raid nun wieder unvollständig ist

ich denke, die drei zitierten meldungen ("finished hot-removing", "raid degraded", "disk disconnected") werden genauso ausgegeben, wenn ich im laufenden betrieb eine raid-platte von hand rausziehe. mit keinem wort geht das protokoll hier auf einen etwaigen festplattenfehler (schadhafte sektoren, schlechte smart-werte ...) ein.

ist das aufgeführte "hot-removing" aus sicht des systems immer ein akt "höherer gewalt" (den es nur zur kenntnis nehmen und vermelden kann) oder kann das system selbst einen solchen vorgang einleiten, ohne dass die kontakte wirklich abgezogen wurden?

daraus ergäben sich für mich die folgenden fragestellungen bzw schlussfolgerungen:

1. wenn in der nas-terminologie damit lediglich das rein physische trennen des kontakts gemeint ist, bliebe ja nur der "wackelkontakt" -- und die frage nach fehlern auf dem datenträger stellten sich zu diesem zeitpunkt noch gar nicht -- fast zwingend müsste nescafegold dann von "verspannter" komponenten-geometrie als ursache für ein spontanes abstöpseln der platte aus- und entsprechende maßnahmen angehen ...
2. ist, in diesem licht betrachtet, das zeitgleiche/zeitnahe vorhandensein/auftreten von festplattenfehlern -- die, wohlgemerkt und merkwürdigerweise, nicht vom system, sondern erst nachträglich mit externem werkzeug festgestellt wurden -- dann nur ein unglücklicher zufall, mit dem leider immer zu rechnen ist? dann können wir nur auf weiterhin gutes einvernehmen mit plattenherstellern hoffen und dies nescafegold als wunsch mit auf den weiteren rma-weg geben.

natürlich wünsche ich ihm, dass mit der dritten garantie-platte die strähne abbricht ...

um nochmal auf die einstiegsfrage von glauter zurückzukommen: jeder einschaltvorgang (dem zwangsläufig auch ein ausschalten vorausgeht) eines elektrischen gerätes nagt grundsätzlich an dessen lebensdauer (das war schon bei der glühbirne und der neonröhre so), die betriebsstunden ebenso. benutze ich eine glühbirne immer wieder als morsegerät, darf ich mich nicht wundern, dass sie lange vor erreichen ihres vermutlichen glüh-lebensalters abnippelt (und der schalter wohl auch).

runterfahren/ruhezustand (auch über zeitplan), hochfahren/aufwecken (per zeitplan und auch mittels wol) oder dauerlaufen lassen, bei dieser abwägung spielt die häufigkeit der schaltvorgänge sicher eine entscheidende rolle. und der wirtschaftliche aspekt sollte selbstverständlich in betracht gezogen werden: inwieweit trägt eine durch runterfahren/ruhen erzielte energiekostenersparnis zum abfedern von beschaffungskosten eines ersatzgerätes bei.

mit ihrer praxis stehen reddiabolo und fsc830 da ganz sicher auf der gewinnerseite. betreibern mit einem wesentlich anderen nutzungsbedarf, wie zb upspin oder snatch, bleibt dagegen kaum eine andere wahl, als auf durchlauf zu stellen. und dient der server einer großen zahl von nutzern, die rund um die uhr immer wieder darauf zugreifen, sind auch ab-/einschalt-szenarien (zeitplan, wol) nicht zweckmäßig, da lästig für angemeldete wie sich anmeldende benutzer.

eine für mich praktikable nutzungsvariante: nas (dient der datei-sicherung/-archivierung und als medienzuspieler) ist ausgeschaltet (ruhezustand), wird bei zugriff durch einen kleineren nutzerkreis (familie, freunde) per wol eingeschaltet, nachts, wenn nötig, mittels zeitplan (1, 2, 3 uhr) in ruhezustand versetzt und schläft häufig bis in die späten nachmittags- oder frühen abendstunden, manchmal auch ganz durch.

wir sind alle sterblich, auch mein nas.

nun denn (jetzt in zimmerlautstärke), als erstes ein großes danke an warpcam - genau dieses hebelchen hatte ich verzweifelt gesucht. jetzt läuft's mit dem spontantranskodieren, wie ich mir das vorgestellt habe.

und da wir alle die qnap-beschreibung ja kennen, deren (formal nicht korrekte) zitierung ganz und gar nicht als beschwerde gedacht war, sondern eigentlich nur mein verständnis des ganzen sachverhalts unterstreichen, bestätigen sollte, kann, lieber christian, dieses zitat einfach wegbleiben und damit auch der grund für ein etwaiges löschen meiner anfrage. d'accord?

wenn ich in der file station für eine videodatei "wiedergabe" auswähle, bietet mir das menü unter spontantranskodierung verschiedene ausgabeformate an:

spontantranskodierung_admin.PNG

nach auswahl eines gewünschten formats wird der film sauber abgespielt/gestreamt, und nicht nur mit mp4 als quelldateiformat, sondern auch mit ts und mpg. so weit, so gut ...

das gelingt allerdings nur, wenn ich mich als admin angemeldet habe. einem nutzer bleibt dies verwehrt; bei ihm stellt sich das menü ziemlich abgespeckt wie folgt dar:

spontantranskodierung_nutzer.PNG

ein ausgiebiger schriftwechsel mit qnap-support hat keine lösung gebracht. in der bisher letzten antwort wird lapidar behauptet, allein der admin könne spontantranskodierung nutzen.

wenn dem so wäre (was ich nicht glauben will), widerspräche das doch einem der vornehmsten zwecke eines nas, nämlich vielen benutzern - und gar nicht in erster linie dem admin, dem hausmeister - den zugriff auf freigaben zu ermöglichen, eben auch auf filme, und das mit der möglichkeit, einen stream an die jeweilige leistungsfähigkeit des abspielgerätes anzupassen. die können doch nicht alle mit admin-rechten ausgestattet werden!

qnaps produktbeschreibung zur echtzeit-transkodierung kann ich nur dahingehend interpretieren, dass die eigentliche zielgruppe für das produktmerkmal "spontantranskodierung" die benutzer (ohne admin-rechte) sind - und nach meinem verständnis von einem als cloud genutzten nas ergibt sich auch nur auf diese weise ein sinnvolles konzept bzw werkzeug.

seh ich das völlig falsch oder überseh ich nur eine diesbezügliche einstellmöglichkeit, zb im multimediamanagement/spontantranskodierung oder sonstwo?

wäre sehr dankbar, wenn mir da jemand auf die sprünge helfen könnte ...

danke an dr_mike für die hübsche überarbeitung meiner letzten mitteilung ...

qnap-support hat mich gebeten, verbindungsprotokolle und dumplogs zu schicken - was ich getan habe (warte auf antwort). allerdings finde ich, dass es für die experten dort doch eigentlich ein leichtes sein müsste, das szenario mal nachzustellen und zu sehen, was sache ist. vor allem, da mein bekannter mit dem gleichen sachverhalt konfrontiert ist, kann es ja nicht mehr darum gehen, mögliche benutzer- und anschlussbedingte ursachen aufzuspüren, denn es sieht doch jetzt sehr nach einem grundsätzlichen, in den geräten bedingten problem aus. natürlich könnte es noch an einer von mir vorgenommenen einstellungsänderung im gerät liegen. dann müsste mein freund ja zufällig das gleiche getan haben.

dr_mike, hab in deinem profil gesehen, dass du mit jeder menge qnaps unterwegs bist. könntest du nicht mal einen kleinen verifizierungsversuch laufen lassen? kann mir auch vorstellen, dass du's schon getan hast???

hab wireshark noch nicht eingesetzt. bin aber nun - trotz des gelungenen ftp-transfers innerhalb des lan - aufgrund neuer erfahrungen ziemlich überzeugt, dass es am nas selbst liegt. der grund ist in meiner anfrage an qnap-support zu lesen:

Zitat

***********************************************
nachdem ich als letzte maßnahme, wie von herrn müller empfohlen (ticket #MDT-529-62224), das nas ts-251 von grundauf neu aufgesetzt hatte, ergab sich keine verbesserung:

das nas bricht den empfang einer einzelnen, aus dem internet gesendeten datei – reproduzierbar, also jedesmal – nach 2:12 stunden (plusminus 10 sekunden) ab.

alle vergleichenden versuche mit anderen ftp-servern als empfänger (pc mit filezilla-server, fritzbox mit angeschlossener externer festplatte) werden dagegen mit erfolg zuendegeführt, auch wenn der transfer einer einzelnen datei 4, 6 oder gar 10 stunden in anspruch nimmt – kein abbruch. abgeschickt werden die dateien übrigens vom entfernten computer mittels dateimanager (windows-explorer).

obwohl aufgrund der vergleiche eigentlich klar ist, dass die ursache für diese zeitlich offenbar genau vorgegebenen transfer-abbrüche beim ts-251 zu suchen ist, blieb ein kleiner rest unsicherheit, ob nicht vielleicht doch die beteiligten router oder die anschluss-dienstleister verantwortlich sind.

nun hat ein bekannter kürzlich ein qnap ts-853a in betrieb genommen und stellt bei diesem gerät exakt das gleiche verhalten fest: abbruch eines ftp-empfangs (eine große datei) aus dem internet nach 2:12 stunden. und auch dort wurden versuche mit anderen ftp-servern gemacht, die positiv verliefen.

andere netzwerkumgebung, andere router, andere provider mit unterschiedlichen down- und uploadgeschwindigkeiten und unterschiedlichen leitungstechniken – nun ist so gut wie hundertprozentig sicher, dass es sich um ein grundsätzliches problem des qnap-nas-servers handelt, und auch, dass nicht mein ts-251 vielleicht ein bedauerlicher einzelfall sein könnte.

bitte gehen sie der sache auf den grund und lassen sie es mich wissen, wenn sie eine erklärung/lösung gefunden haben.

**************************************************

Alles anzeigen

wenn also (außer dem nas) einer der an der übertragung beteiligten (router, provider) etwas gegen den transfer einer datei hätte, der länger als 2:12 stunden dauert, warum schlägt er dann nicht ebenso zu, wenn der empfänger ein anderer ftp-server ist?

hab als, wie vorgeschlagen, von einem pc mit auf 10 mbit/s begrenzter übertragungsrate eine ausreichend große datei mittels ftp an die lan-ip-adresse/freigabeordner des nas geschickt. der transfer hat gut 4 stunden gedauert und wurde vollständig ausgeführt.

ergeben sich nun aus diesem sachverhalt weiterführende schlussfolgerungen?

entschuldigung, wenn ich da ein wenig verwirrung gestiftet habe. in der tat handelt es sich bei dem geschilderten abbruch/timeout um UPLOADS, sagen wir von B, C oder D nach A, und zwar über das internet.

situation an B, C, D:

- unterschiedliche provider mit unterschiedlichen upload-geschwindigkeiten
- unterschiedliche routermodelle
- windows-arbeitsgruppen-netzwerk mit windows-7- oder windows-10-rechnern; für die uploads wird windows-explorer als ftp-client verwendet

situation an A:

- telekom-anschluss, 16 mbit/s (downstream)
- fritzbox 7490 mit eingerichtetem dynamischem dns
- windows-arbeitsgruppen-netzwerk mit qnap-nas ts-251 sowie windows-7- und windows-10-rechnern mit filezilla-servern

die geräte in netzwerk A haben vom router per dhcp ihre ipv4-adressen erhalten, die dann im router reserviert wurden. außerdem wurden weiterleitungen an die ports 21 der geräte eingerichtet und ausreichend große port-bereiche für passives ftp definiert.

szenario 1 (ziel: nas):

von B, C oder D wird eine ftp-übertragung/-upload EINER EINZIGEN großen datei nach A gestartet, und zwar AN DAS NAS. die dateigröße ist so bemessen, dass auf jeden fall mehr als zweieinhalb stunden für den transfer benötigt werden. jedesmal, nach ziemlich exakt 2:12 stunden (plusminus 20 sekunden) bricht der upload ab. an B, C und D meldet windows einen "ftp-ordnerfehler" (details: das zeitlimit für den vorgang wurde erreicht).

szenario 2 (ziel: pc/filezilla-server):

von B, C oder D wird dieselbe datei nach A hochgeladen, diesmal nicht an das nas, sondern AN EINEN DER PC mit FILEZILLA-SERVER. der transfer, der je nach upload-geschwindigkeit vier bis zwölf stunden dauert, wird OHNE abbruch, auch OHNE unterbrechung (mit anschließender wiederaufnahme), fehlerlos abgeschlossen.

szenario 3 (ziel: nas):

von B, C oder D werden mehrere kleinere dateien, die in der summe aber auch mindestens zweieinhalb stunden erfordern, nach A auf das nas hochgeladen - kein abbruch nach 2:12 stunden, alle dateien landen unversehrt im zielordner - auch nach acht stunden und mehr übertragungsdauer.

szenario 4 (ziel: pc/filezilla-server):

wie in szenario 3 ohne abbruch

es bleibt das bislang nicht erklärbare auftreten des 2:12-stunden-timeouts, und zwar NUR beim upload EINER großen datei auf das qnap-nas.

nach mehreren versuchen können wir festhalten, dass die uploads auf einen filezilla-server ohne irgendeine unterbrechung abläufen. zwischen der meldung "(000009) 25.03.2016 11:24:14 - 'benutzer' (###.###.###.###)> 150 Opening data channel for file upload to server of "/Tatort (980).ts"" und dem erfolgreichen abschluss "(000009) 25.03.2016 13:57:38 - 'benutzer' (###.###.###.###)> 226 Successfully transferred "/Tatort (980).ts"" gibt es keine weiteren vermerke über irgendwelche unterbrechungen.

dieser seltsame 2:12-timeout tritt nur dann auf, wenn das nas bzw dessen ftp-server mit von der partie ist.

in "kleinen" (bis zu 14 stunden) gegenproben haben wir auch downloads auf das nas (mittels windows-explorer) durchgeführt, die alle problemlos abgeschlossen wurden. aber das ist ja wohl nicht aussagekräftig, da hier der windows-explorer als ftp-client verwendet wird und der transfer dann auf die netzwerkfreigabe des ts-251 erfolgt.

der kundendienst von qnap konnte bislang auch nichts wirklich sachdienliches beisteuern, außer folgenden empfehlungen

1. firmware erneut installieren
2. einfacher reset
3. erweiterter reset

1. und 2. haben nichts bewirkt und - obwohl's sehr aufwendig ist und ich eigentlich auch nicht dran glaube - werde ich auch noch 3. angehen; man will ja nichts unversucht lassen ...

und selbst wenn es damit behoben würde, bleibt doch die frage, durch was/wen kommt es zu dieser immer gleichen zeitbegrenzung?

übrigens hab ich mich auch mal an die doktoren von avm gewendet. bin gespannt, ob da vielleicht was erhellendes zurückkommt; aber wahrscheinlich werden die mich an qnap zurücküberweisen.