Beiträge von nulobez

    Behauptet wer ?


    Aber aus der Antwort schließe ich das dir die Gefahr nicht bewusst ist.


    Nachdem es jahrelang aus QNAPs Sicht (und bei Synolgy immer noch) zumindest als so ungefährlich eingestuft wurde (ist), daß man den Gastzugang problemlos auf eigene Gefahr und Risiko einrichten kann, muss ja wohl neuerdings eine Gefahr herrschen, die vorher so nicht existierte :-p


    Zudem frage ich mich, was diese "Das ist gefährlich !!!1elf" Moralapostelei soll. Erinnert mich irgendwie an die "Das ist aber verboten !!!1elf"-Rufe in manchen Funktechnik-Foren, wenn dort die Frage nach technischen(!) Empfangmöglichkeiten aufkommt. Also lieber wieder zurück zum Thema:


    Ich habe gerade Mail von QNAP bekommen, daß der "böse und ach so gefährlche" Gastzugang bald wohl wieder konfigurierbar sein wird:

    Zitat von QNAP Support

    Hallo Hr. ***** ,

    der Fehler wurde bestätigt und gelöst, in der Firmware 4.3.6.0993 wird es wieder wie gewohnt funktionieren.

    Danke für Ihre Hilfe unsere Produkte zu verbessern

    Ja solche Clients gibt es. Das sind i.d.R. aber keine Windows Systeme sondern Drucker/Scanner/Faxe, CAMs oder andere IoT Systeme.

    Wer spricht denn hier von (ausschließlich) Windows? Das Ding ist ein NAS und steht dem ganzen Netz aus unterschiedlichsten Clients für unterschiedliche Zwecke zur Verfügung.


    Aber danke für den Hinweis auf einen Scanner; daran dachte ich noch gar nicht: Der EPSON WF 7610 dürfte jetzt auch Dank QNAPs "Bemutterung"(?) am Scannen in eine QNAP-Freigabe gehindert sein. Und jeder, der sich die Scans abholen will, müsse sich nun an einer NAS-Freigabe anmelden?


    Jagnix:


    Was mag seit dem "Vernageln" (Ob absichtlich oder aufgrund eines Bugs in der neuesten Firmware, welche die Freigabe des Gastzugangs per Webinterface nicht mehr ermöglicht, sei dahingestellt) im Vergleich zu den

    letzten geschätzt 8 Jahren "Gastbetrieb" gefährlicher geworden sein? Warum ist ein Synology - oder diverse Linux-Gastfreigaben - im gleichen Netz ungefährlicher?


    Nee: IMNSHO ist das einfach ein Bug in der neuesten Firmware. Da ist bei QNAP ein Sicherheitspatchler etwas übers Ziel hinausgeschossen.


    Derweil behelfe ich mich mit dem Patch aus dem englischen QNAP-Forum und warte und hoffe auf Korrektur im nächsten Firmware-Update.

    Aber was ist so schwer daran eine Gruppe zu erstellen, die auf eine Freigabe zu berechtigen und dann User zu erstellen.


    1.) Es gibt Clients, die beherrschen die Anmeldung an einen SMB-Share mit Benutzer/Passwort nicht. Jene benötigen zwingend den Gast- (Anonymous-) Zugang.


    2.) War das hier die Frage? Oder nicht eher die, was QNAP da mit dem letzten Firmware-Update veranstaltet hat, auf daß der Gastzugang nicht mehr erreichbar sei? Wem bewusst ist, welches Scheunentor er mit dem Gastzugang aufreisst, sollte dies auf eigenes Risiko wie bisher machen können/dürfen und nicht von einem Firmware-Update bemuttert werden!

    Gibt es schon eine Rückmeldung von QNAP?

    Zuerst kam eine Rückfrage, mit welchem Benutzernamen ich mich denn als Gast anmelden wolle: Mit "gast" oder mit "guest" #-)


    Im zweiten Anlauf, nachdem meine Antwort "Mit gar keinem Benutzernamen! Genau dafür dient doch der Gastzugang" lautete, wollte der Supporter ein "Dumplog von der NAS" von mir haben, auf daß er ihn zur Behebung des Bugs den Entwicklern in Taiwan weiterleite.

    Unable to access NAS as guest following firmware update to v4.3.6.0979


    BTST.


    Erstmal irgendwie beruhigend, daß ich nicht der Einzige bin, der nicht nur das "Vernageln" des Gast-Zugriffs durch den letzten Firmware-Update bemerkt hat, sondern ihn auch benötigte :)


    Jetzt war ich mal so mutig, den dort vorgeschlagenen Patch bezüglich der smb.sh gaaaanz vorsichtig durchzuführen. Es scheint gehilft zu haben.


    Danke auch an die hiesigen User, die nicht nur mit dem "Gastzugang ist böse™"-Knüppel auf mich eindreschten, sondern Konstruktivität an den Tag legten.


    Bleibt jetzt abzuwarten, ob QNAP drauf reagiert. Auch ich habe derweil den dortigen Support dementsprchend kontaktiert.

    SMB.conf


    Soweit war ich inzwischen auch und fand dort den Eintrag "guest account = guest". So viel (eher wenig) ich von SMB verstehe, sollte für einen funktionierenden Gastzugriff dort aber "guest account = nobody" stehen. Das überschreibt mir das NAS aber bei jedem wohl nach smb.conf-Änderung notwendigem Restart wieder zurück auf

    "guest account = guest". Ein ebenfalls testweise eingefügtes "usershare allow guests = yes" bleibt zwar heile, nutzt aber wohl nichts.


    Oder müssen die Änderungen in /etc/default_config/smb.conf erfolgen?

    Was das Zitieren angeht: Ich find hier nur Buttons für "Inhalt melden" und "gefällt mir"


    Und nochmal, was das Anmelden an die SMB-Shares des QNAP angeht, wozu hier jemand schrieb, es sei nicht notwendig:


    "Nicht notwendig" war es nur vor dem letzten Firmware-Update. Seit das drauf ist, gehen sowohl unter Linux als auch unter Windows Fenster auf, die sinngemäß behaupten, es sei ein Passwort notwendig.


    Unter Nautilus heißt das "Für qnap1a wird ein Passwort benötigt" mit der zwangsweisen Eingabe von Benutzername und Passwort. Mit den Credentials des qnap Admins geht das zwar, ist aber wohl nicht Sinn der Übung. Dieses Anmeldefenster fehlte vor dem Update im Nautilus völlig. Der Thunar bot vor dem Firmware-Upgrade die Wahl zwischen "Anonym vebinden" oder "Als Benutzer vebinden" an. Hier ein Screenshot vom Synology, wo das nachwievor geht:


    thunar-vor.png


    Am qnap geht das nach dem Firmware-Update nicht mehr, es wird zwangsweise Benutzer und Passwort angefordert:


    thunar-nach.png


    Wie bekomme ich den Zustand wieder zurück, wie er vor dem Firmeware-Update herrschte?


    Interessanterweise gibt es in der QNAP-Oberfläche nun ein Menü, in dem augenscheinlich (offensichtlich?) das Verhalten des Gastzugriffs auf Shared Folders geregelt werden kann (könnte?):


    guest-restrict.png


    Mit der Einstellung "Restrict anonymous users …" auf "disabled" sollte doch der Gast/Anonymous-Zugriff möglich sein. Wie er es vor dem Firmware-Upgrade auch war.


    Ich danke zwar euch allen für die genannten Würgarounds, die durchaus diesen Bug(?) umgehen helfen, aber dazu müssten zum Beispiel auch noch etliche fstab-Einträge mehrerer Linuxkisten von zum Beispiel


    Code
    //192.168.200.72/p4tb/driveH/music.flac /media/nas.flac cifs guest,iocharset=utf8 0 0


    von "guest" auf (vermutlich. Ich habe nicht die 1000%ige Linux-Ahnung und würde deswege beim bis dato funktionierendem "guest" bleiben)


    Code
    uuid=anmeldename, password=password


    umgestellt werden. Diese Mounts liegen seit dem Firmwareupdate auch tot

    Nochmal an alle. Ich finde hier in diesem Forum leider ad hoc keinen Button, um auf jede Antwort getrennt eingehen zu können:


    1. Mögliche(!) Sicherheitsrisiken sind mir bewusst, jedoch lief das NAS hier über Jahre(!) problemlos mit Gastzugriff auf die Shared Folders. Damit von außen jemand drankäme, müsste er erst einen Weg durch meinen Router/meine Firewall aufs lokale Netz finden. Und wenn der gefunden wäre, hätte ich weiß Gott andere Probleme, als einen Gastzugang zu den Shared Folders des QNAP!


    2. Ich will und kann nicht in allen Clients hier eine SMB-Anmeldung verhackstückeln. Solange der Gastzugang auf die Shared-Folders noch möglich war, war das die Lösung schlechthin.


    3. Nachwievor würde ich eigentlich gerne nur wissen, was genau mit dem letzten Firmwareupdate geschehen ist, weswegen der Gastzugang auf die Shared Folders nicht mehr möglich ist. Liest hier vielleicht jemand von QNAP mit, und möchte mir das verraten?


    4. Gibt es eventuell eine Firmware Downgrade-Möglichkeit auf die Version vor 4.3.6.0979? Damit ging der Gastzugriff ja noch.

    Genau das will ich nicht (wie packe ich zum Beispiel eine Linux-Kiste in dieses Szenario?) und habe es bis zum letzten Firmware-Upgrade auch nicht gebraucht. Irgendwas, was einen bisher jahrelang möglichen Gastzugang - Linux nennt es "anonymous" - erlaubt hat, ist da wohl jetzt abgeschaltet worden. Wie schalte ich es wieder ein?


    Vileleicht neue SMB-Version aufm NAS, welche grundsätzlich eine Authorisierung verlangt, selbst wenn nachwievor überall der Gast-Zugriff freigeschaltet ist?

    Dieses Anmeldefenster kommt ja erst seit dem Firmware-Upgrade. Die dort genannte Domäne saugt sich wohl das jeweils anmeldende BS aus seinen eigenen Fingern.


    "Vertrauensstellung"? Vor dem letzten Upgrade ging das halt als "Guest Access" ohne jegliche Anmeldedaten.


    Aufm parallel betriebenen Synology geht es nachwievor wie gewohnt. Ein Windows kommt sofort aufs dortige NAS, das Linux erlaubt ein "anonym verbinden", wie es zuvor auch aufm QNAP ging:

    syno-smb.png

    So:


    passwort.png


    Taucht erst nach dem letzen Firmware-Update auf. Bereits beim Verbindungsversuch und nicht vielleicht erst, nachdem ich überhaupt an Freigaben komme und eine solche öffnen wollte. Hier mal ab Linux. Ab Win7 schaut es vergleichbar aus:


    win7pass.jpg


    Interessantereweise klappt der Zugriff hier wie dort mit dem QNAP-Administrator als User und dessem Passwort. Das ist aber wohl nicht gerade Sinn der Übung! Dann lieber weider den ursprünglichen "Guest Access".

    Moin!


    Hier läuft ein QNAP TS 851 vornehmlich als Netzwerkspeicher. Um von allen möglichen PCs aus Daten darauf ablegen zu können, habe ich schon von Anfang an den Gastzugriff gestattet. Seit dem aktuellen Firmware-Update auf die 4.3.6.0979 verlangt jeder PC - egal ob Windows oder Linux - Usernamen und Passwort. Bereist beim Verbindungsversuch und nicht erst beim Versuch, einen Freigabeordner zu öffnen. "Guest Access" steht aber überall (wo überall eigentlich? Gibt's da neuerdings neue Stellen?) nachwievor auf "Guest Access Right: Full Access", was wohl damals notwendig war, einzustellen, um ohne User/Passwort darauf zugreifen zu können.


    Was wurde geändert? Wo muss ich schrauben?


    TIA,

    Ulrich


    P.S.: Sollten sich Schreibfehler in diesem Post befinden, werde ich sie diesmal nicht nachträglich korrigieren. Als ich sowas das letzte Mal tat, fing ich mir einen Rüffel wegen vorgebliche Doppelpostings ein.

    Nein, in der .htaccess sollte eigentlich der Pfad stehen in dem die Authorisierungsdatei liegt.

    Möglich, daß ich es damals genauso machte.

    Es gibt keine htpasswd

    Stimmt. Nur eine .htpasswd :) Die man auch statt einer .htusers verwenden kann.

    In der .htaccess müsste das wie folgt aussehen (Beispiel):

    Schön. Aber wo finde ich die? Genauer: Wohin ist sie entschwunden? Die finde ich nirgendwo (mehr wieder).

    Dann heisst das File das Du suchst .htuser

    Auch die finde ich nirgendwo. Auch keine .htusers, wie sie IMHO heißen müsste.

    Edit: was hast Du eigentlich vor?

    Usernamen und Passwort zum Zugriff auf http://xxx.yyy.de:6789 ändern. Das ist mein Webserver aufm QNAP. Wie man unschwer sieht, ist dort der Passwortschutz aktiv. Nur die Files - .htaccess und .htpasswd (alternativ .htusers) - die den realisieren, finde ich zwecks Ändern ums Verrecken nicht mehr wieder.


    Da er aber wirkt, müsste eigentlich in der .htaccess ein "AuthUserFile /pfad/zur/datei/.htpasswd" (Oder von mir aus auch .htusers :)) und im dort referenzierten AuthUserFile ein "Username:md5-Hash vom Passwort" stehen. Sagte ich BTW schonmal, daß ich davon nix wiederfinde …?

    Nein, in der .htaccess sollte eigentlich der Pfad stehen in dem die Authorisierungsdatei liegt.


    Steht er auch. Derweil habe ich sowohl ".htaccess" wie auch ".htpasswd" (Nur echt mit dem "." am Anfang :)) gefunden. Sie stehen schön brav in genau dem Verzeichnis, was es zu schützen galt:


    .htaccess:

    Options +Indexes
    AuthName "Finger weg. Sonst sind sie ab!"


    (das sollte jetzt auch http://ufh.qi3.de:6789 melden)


    AuthType Basic
    AuthUserFile /share/CACHEDEV1_DATA/p4tb/driveH/music.flac/.htpasswd
    Require valid-user


    .htpasswd (in genau dem in .htaccess angegebenem Pfad):


    username:MD5-Hasch des Passworts


    Nur "find" hat die ums Verrecken nicht zu finden vermocht. Und ich hatte das "Muss im DocumentRoot des Apache stehen"-Brett vorm Kopf. Leg Dich wieder hin: Danke für Deine Geduld mit mir. Wo kann man das Ticket closen?

    Aber "find" kennt es ;).

    Sorry. Die Existenz von "find" hatte ich verdrängt, weil "find" elendig lange im Vergleich zu "locate" dauert. Hab's derweil abgesetzt und bin zu seltsamen Ergebnissen gekommen: Mehrere .htaccess wurden gefunden, aber ausschließlich in meinen Shared Folders. Auf dem NAS liegen nämlich auch Kopien meiner extern gehosteten Websites. Da waren auch .htaccess dabei. Eine .htpasswd fand sich dagegen nirgendwo.


    Ich bin zwar jetzt nicht gerade der Apachen-Spezialist, aber müssten beide denn nicht im "DocumentRoot" des Apache liegen? Das wäre hier "/share/Web". Da ist außer

    Code
    lrwxrwxrwx  1 admin administrators   37 2018-05-23 10:54 CF64 -> /share/CACHEDEV1_DATA/.qpkg/CF64/CF64/drwxrwx---  2 admin administrators 4096 2015-09-29 15:22 common/-rwxrwx---  1 admin administrators 1601 2015-10-07 10:14 index.php*lrwxrwxrwx  1 admin administrators   49 2015-09-29 15:22 prestashop -> /share/CACHEDEV1_DATA/.qpkg/PrestaShop/prestashop/drwxrwxrwx  2 admin administrators 4096 2015-11-21 14:17 @Recycle/

    nix. Trotzdem greift der damals angelegte Passwortschutz auch heute noch, wie ich eigentlich in einem Screenshot gezeigt haben wollte: <Extern verlinktes Bild entfernt! Bitte im Beitrag hochladen>


    Mag vielleicht durch irgendein Update die Authentifizierung weg von .htaccess/.htpasswd gewandert sein? Wenn ja, wohin?

    Kannst Du die Dateien nicht über die Filestation und die Erweiterte Suche suchen?

    Damit komme ich doch wohl nur an die Shares aber nicht an die Konfigurationsdaten des auf dem NAS laufenden Apachen, nicht wahr? Daß ich per Telnet oder SSH drauf muss, ist mir schon klar, und eigentlich sollten die auch in /share/Web stehen. Tun sie aber nicht. Wirksam sind sie aber.

    die datein sind versteckt, einfach im windows explorer aktivieren, dass er versteckte anzeigen soll

    Ich besitzte keinen Windows Explorer. Ein "ls -a" sollte dagegen auch versteckte Files anzeigen. Nur, wo bitte finde ich sie? Leider kennt das abgespeckte Linux auf der TS851 kein "locate", sonst könnte ich suchen, wo.

    Moin!


    Sorry, daß ich eure Hilfe brauche, aber ich finde mich auf meinem QNAP-NAS nicht mehr zurecht. Vor Äonen habe ich mal den Zugriff auf den Webserver erfolgreich vernagelt, auf daß jeder Besucher desselben ein


    Extern verlinktes Bild entfernt! Bitte im Beitrag hochladen


    präsentiert bekommt. Die dafür nötigen Einstellungen dürfte ich damals in .htaccess und .htpasswd gemacht haben und sie funktionieren auch heute noch, wie dem Screenshot zu entnehmen ist. Gerne würde ich sie nun ändern, bin aber zu dämlich, den Ort dieser beiden Dateien wiederzufinden: /share/Web ist es nun mal nicht.


    Könntet ihr bitte so freundlich sein, mir auf der Suche nach dem Speicherort behülflich zu sein?


    TIA,

    Ulrich

    Vielleicht ist ja eine Aufteilung der zu sichernden Daten auf zwei Backup-NAS möglich.


    Ich kenne leider Murphy. Der sorgt dann mit Sicherheit dafür, daß der Platz, der auf dem einen noch frei ist, auf dem anderen fehlt.


    Ich habe keine Erfahrung mit den Erweiterungsgehäusen, aber in der Theorie sollte ein fehlendes/ausgeschaltetes Erweiterungsgehäuse bei einem übergreifenden RAID (externe und interne HDD) nicht direkt das RAID übern'n Jordan schicken. Steht zumindest so irgendwo in den Tiefen der QNAP-Webseite.


    Mhhhh. Ich werde mal eine Nacht drüber schlafen. Bis dahin erstmal herzlichen Dank für Deine Anregungen …

    Handelt sich ja immerhin um USB 3.0, ich denke da wird 1x GBit/s Netzwerk immer noch der Flaschenhals sein.

    Aber das Zusammenfügen der auf die Platten verteilten RAID6-"Scheibchen" ginge da wohl nicht mehr mit SATA III- sondern nur noch mit USB3-Geschwindigkeit. Hätte das nicht höhere Latenz zur Folge?


    Zudem hat mich gerade xtivate (QNAP Integrator) darauf aufmerksam gemacht, daß das zwar ginge, aber eine ziemlich wackelige Angelegenheit werden würde: Fiele eines der beiden Geräte aus - und sei es nur durch Unterbrechung der USB-Strippe - wäre das RAID6 sofort übern Jordan, weil dann gleich mehr als zwei Platten ausfielen.

    Was ich meinte wäre ein drittes 8-Bay NAS in das Du die übergebliebenen 4TB Festplatten steckst, da ich (persönlich) den Preis für die Erweiterungsgehäuse als zu hoch empfinde, wenn man sich anschaut was ein weiteres 8-Bay kostet. Für etwas mehr gibt es ein TS-853 und etwas weniger ein TS-831...habe nur mal fix bei einer Preissuchmaschine geschaut.

    Vermutlich habe ich mich ungeschickt ausgedrückt: Damit hätte ich dann zwei "Backup"-NAS, die beide zu klein wären, um das erste NAS spiegeln zu können. Also nix gewonnen …