Beiträge von outsch

Meine TS251+ musste leider nach völligem Crash (keine Zugriff mehr auf Verwaltung) und vollständigem Neuaufsetzen (Neuinitialisierung mit neuem RAID-Aufbau und Datenwiederherstellung aus dem Backup) neu eingerichtet werden. Nach 5 Tagen Daten laden und einrichten habe ich jetzt wieder Zugriff von extern aktiviert und QSYNC aktiviert.

Ein User arbeitet mit 4 verschiedenen Laptops (1 x Win 10, 3 x Win 8.1), auf denen alle unverändert die letzte Version 5.0.1.0319 von QSYNC installiert ist. Auf einem der 4 Rechner war die Synchronisation (knapp 3.000 Dateien mit 5,9 GB) in wenigen Minuten erledigt. Auf den anderen drei Rechnern läuft die Synchronisation mittlerweile seit fast 48 Stunden, man sieht, dass nur alle paar Sekunden/Minuten eine Operation stattfindet. Alle Rechner befinden sich im lokalen LAN mit reellen Übertragungsgeschwindigkeiten > 50MB/s.

Auffällig ist auch, das in QSYNC Central -> Ereignisprotokolle überhaupt keine Einträge vorhanden sind. Die Benutzer und Geräte werden korrekt angezeigt, aber keine Logs.

Vor der Neuinitialisierung der NAS lief QSYNC auf allen vier Rechnern problemos, Jede Dateiopration (Anlegen, Löschen, Verändern) wurde innerhalb von Sekunden synchonisiert, seit mehreren Jahren ohne ein Problem.

Hat QSYNC eine Verwaltungs-Datenbank, die evtl. neu indiziert werden muss? Gibt es irgendwelche weiteren Einstellungen, die geändert werden sollten/können?

Da es leider bei QNAP praktisch keinen Support gibt, bin ich für jeden Hinweis dankbar, leider werden offenbar selbst diese Standardprogramme immer schlechter...

Aktuell geprüft: in 30 Minuten 20 von 2995 Ereignissen verarbeitet... - das ist lächerlich!

Hi, liest sich als ob Ihr zwei hier mehr Ahnung als ich habt: Ich habe einen täglichen RTRR Backup job, der aber die Versionierung ebenfalls nicht erlaubt. Der ganze Dialog ist zwar sichtbar, aber ausgegraut und deaktiviert.

RTRRTimePlanP1.JPG

Habe HBS auch auf der Backup-NAS laufen, und weder beim Versuch den bestehenden Backup-Job zu ändern noch beim Anlegen eines neuen Jobs lässt sich die Versionierung einschalten. Dabei hatte sich schon mal funktioniert:RTRRBackupNasFoldersP1.JPG

Aus irgendeinem unerfindlichen Grund lässt sich das aber nicht mehr einstellen.

Seltsam ist auch das wenn der Job läuft und ich auf die Back-NAS schaue, kein eingehender Job angezeigt wird obwohl er läuft und auch (ohne Versionierung) sichert.

Habt Ihr irgendeine Idee, wie man das hinkriegt?

Das ganze HBS-Backup ist ein echter Krampf...

Hallo, klicke mich schon mehrere Tage erfolglos durchs Web und habe jetzt Dein doch etwas anspruchsvolleres Composer file gesehen.

Was ich möchte: Eine Umgebung (also Container-Applikation), die aus php8, httpd (Apache) und phpmyAdmin besteht einrichten.

Hintergrund ist eine per Containerstation gezogene Joomla-Installation, an der ich arbeite und die jetzt mal wieder einen PHP-Update benötigt hat. Bei dem Update habe ich mir fast die Entwcklungsarbeit von 2 Jahren kaputt gemacht, weil das ein Kombi-Image aus Joomla und PHP ist und Joomla bei der Neuinstallation fast alles kaputt gemacht hätte.

Also will ich einfach nur eine Applikation, mit der ich die aktuellen Versionen von php, Apache und php myAdmin habe - Ohne Joomla. Außerdem um einiges an PHP-Programmierung zu testen.

Nach vielen Stunden habe ich ein Docker Compose file, das folgendermaßen aussieht:

version: "3.4"
services:


php:
image: php:latest
container_name: container-php
environment:
- WORKDIR=/var/www/html
volumes:
- /share/Web/phplatest:/var/www/html
command: php


apache2:
image: httpd:latest
container_name: container-apache
environment:
- PHP_SOCKET=php:9000
volumes:
- /share/Web/phplatest:/var/www/html
- /share/appdata/phplatest/apache2:/etc/apache2
- /share/appdata/phplatest/apache-log:/var/log/apache2
- /share/appdata/phplatest/php:/usr/local/etc/php
- /share/appdata/phplatest/php/custom.d:/usr/local/etc/php/custom.d
ports:
- "9500:80"
- "9501:443"
depends_on:
- php


phpmyadmin:
image: phpmyadmin/phpmyadmin:latest
container_name: container-phpmyadmin
ports:
- "9502:80"
environment:
- PMA_HOST=192.168.178.54
- PMA_PORT=3306
depends_on:
- apache2

Mit Erstellen->Applikation in der Container Station kann ich damit auch die Applikation erstellen, aber nur der phpmyAdmin und der Apache-Container laufen, php will um Verrecken nicht starten.

Hat irgendjemand eine Idee? Braucht es einen Entrypoint wie bei der manuellen Erstellung eines Containers? Wenn ja, was sollte dieser sein? Ist der command:php in Ordnung so?

Leider muss man sich mit den Uralt-Versionen von php auf QNAP immer mit so was rumschlagen. Jeder Tipp st sehr willkommen!

Hallo,

auf meiner QNAP TS251+ taucht seit einigen Tagen immer nach Neustart die Fehlermeldung auf, das ein MOVE Auftrag einer Datei (Verschieben einer PHP-Datei innerhalb einer Ordnerstruktur einer Website) wieder gescheitert ist. Ursache ist ein Rechteproblem, offenbar war der Auftrag unter einem Benutzerkonto erfolgt, das nicht die entsprechenden Rechte besitzt.

Aber die FileStation scheint das immer wieder (nach Neustart der NAS) zu probieren. Wie kann ich den "hängnenden" Auftrag löschen? In Dokumentation und FileStation-Einstellungen finde ich nirgends so etwas wie eine Joblist, die man evtl. löschen könnte.

Hat jemand eine Idee?

Nach vielen weiteren Stunden habe ich jetzt hinbekommen, was ich wollte: Eine im Docker Container laufende Anwendung, die von außen erreichbar ist und deren Verbindung nicht nur über https abgesichert ist, sondern deren Zertifikat auch von den strengen Browsern als gültig angesehen wird und nicht zur Fehlermeldung Zertifikat NICHT SICHER führt. Außerdem kann ich die Konfiguration des Containers (Joomla 3.9.1+php 7.1 + apache) einfach von außen (d.h. über Windows am PC mit Editor) ändern und dort auch die Log-Files ansehen, ohne jedes Mal mit SSH "zu Fuß" mit die Finger zu brechen.

So ganz ohne SSH bin ich aber auch nicht ausgekommen, aber es beschränkt sich auf wenige Schritte:

1. Image ziehen und temporären Container erstellen
   In der Container Station suche ich nach Joomla und wähle in meinem Fall das Tag 3.9.1-php7.2 aus. Der Container wird so konfiguriert, dass er die (bestehende) native Datenbank der NAS nutzt und in einer ersten, temporären Variante die Config-Dateien des Apache zunächst im Container hat - allerdings nur zum Zwecke des Kopierens auf den Host um diese später einfacher im Zugriff haben:
   1. Umgebung:
      JOOMLA_DB_HOST 192.168.xxx.yyy:3306 (wobei xxx.yyy die tatsächlichen IP-Teile darstellen)
      JOOMLA_DB_NAME MeineJoomlaDB
      JOOMLA_DB_USER JoomlaUserName
      JOOMLA_DB_PASSWORD JoomlaPassword
      GID 100
      UID zzzz
      
      GID und UID sind dabei die Gruppen-ID und die User-ID eines separaten Users, unter dessen Identität der Container betrieben wird.
   2. Netzwerk (Ports)
      9100 80
      9101 443
   3. Freigaben (wobei die hostseitig angegebenen Ordner [hier: "joomla-container" und darunter] angelegt, aber leer bis auf den JoomlaOrdner sind sind leer!):
      /share/joomla-container/apache-log -> /var/log/apache2
      /share/joomla-container/php/custom.d -> /usr/local/etc/php/custom.d
      /share/Web/JoomlaOrdner -> /var/www/html
      
      Ich vergebe für den Container den Namen joomla-temporary und nach Klick auf Erstellen zieht die NAS das Image vom Dockerhub und erstellt den Container.
2. SSL Modul aktivieren und Apache-Konfiguration aus dem Container auf den Host kopieren
   1. Mittels SSH (z.B. PuTTY) auf der NAS anmelden
   2. Da das SSL-Modul offenbar noch nicht im Original-Image aktiviert war, gehe ich zunächst in den laufenden Container mit
      docker exec -it joomla-boagle /bin/bash
      und aktiviere dort das bisher fehlende SSL-Modul mit
      a2enmod ssl
   3. Mittels exit verlasse ich den laufenden Container und bin wieder auf der NAS
   4. Ich kopiere nun die gesamte Apache-Konfiguration auf den Host in die zuvor eingerichteten Ordner [hier: "joomla-container" und darunter] mit:
      docker cp -L joomla-temporary:/etc/apache2 /share/appdata/joomla-container
      Der Schalter -L ist wichtig, damit die SYMLINKS mitkopiert werden - so können später Module oder neue Seiten bedarfsweise mit a2enmod aktiviert werden.
      Danach kann ich in der FileStation oder auch im Windows Explorer sehen, dass es nun das Verzeichnis joomla-container/apache2 gibt, das alle Konfigurationsdateien von Apache enthält.
3. Zertifikat bereitstellen
   Das QNAP-Zertifikat, dass ich eigentlich habe, lässt sich nach Freigabe auch herunterladen, aber es hat sich als untauglich erwiesen. Also gehe ich in Systemsteuerung > Sicherheit > Zertifikat & privater Schlüssel und wähle Zertifikat ersetzen und dann Let'sEncrypt und gebe dort meine Domain meinqnapname.myqnapcloud.com ein, deren Verfügungsberechtigung QNAP ja bestätigen muss. Nach wenigen Augenblicken ist das Zertifikat fertig und kann als ZIP-Datei heruntergeladen werden. Ich packe die drei Dateien aus und speichere sie im dazu erstellten Verzeichnis /share/appdata/joomla-container/apache2/certificates aus, dort stehen dann nach:
   1. SSLcertificate.crt
   2. SSLIntermediateCertificate.crt
   3. SSLprivatekey.key
      
4. Finalen Container erstellen
   Ich stoppe den laufenden temporären Container und erstelle auf Basis den nun vorhandenen Images einen neuen, der bis auf eine Änderung gleich konfiguriert wird wie der vorherige temporäre:
   1. Umgebung:
      JOOMLA_DB_HOST 192.168.xxx.yyy:3306 (wobei xxx.yyy die tatsächlichen IP-Teile darstellen)
      JOOMLA_DB_NAME MeineJoomlaDB
      JOOMLA_DB_USER JoomlaUserName
      JOOMLA_DB_PASSWORD JoomlaPassword
      GID 100
      UID zzzz
   2. Netzwerk (Ports)
      9100 80
      9101 443
   3. Freigaben:
      /share/joomla-container/apache2 -> /etc/apache2 Diese Freigabe ist hinzugekommen!
      /share/joomla-container/apache-log -> /var/log/apache2
      /share/joomla-container/php/custom.d -> /usr/local/etc/php/custom.d
      /share/Web/JoomlaOrdner -> /var/www/html
5. Zertifikat installieren
   Ich prüfe ob den Container läuft und stoppe ihn dann wieder. Dann editiere ich die Datei (in WIndows!)
   /share/joomla-container/apache2/sites-available/000-default.conf
   und ergänze sie um folgenden Eintrag:
   <VirtualHost *:443>ServerAdmin meine-mail@adresse.comDocumentRoot /var/www/htmlServerName meinqnapname.myqnapcloud.comSSLEngine onSSLCertificateFile /etc/apache2/certificates/SSLcertificate.crtSSLCertificateKeyFile /etc/apache2/certificates/SSLprivatekey.keySSLCertificateChainFile /etc/apache2/certificates/SSLIntermediateCertificate.crt</VirtualHost>
   Ggf. ergänze ich Servername und e-mail im oberen *:80 Abschnitt ebenfalls und speichere sie.
6. Container neu starten
   Ich starte den Container neu in der Containerstation und kann sowohl auf
   http://meinqnapname.myqnapcloud.com:9100
   als auch auf
   https://meinqnapname.myqnapcloud.com:9101
   zugreifen und bekomme keiner Zertifikatsfehler mehr angezeigt, d.h. die Anwendung läuft von außen (WIndow) konfigurierbar und mit von außen einsehbaren Logfiles und mit gültigem Zertifikat!

Übrigens an Crazyhorse: Erstens ist das immer noch ein Entwicklungsprojekt und wird später selbstverständlich bei einem Hoster gehostet, Aber während der Entwicklung ist es eben viel bequemer, alles lokal zu haben. Und selbstverständlich ist das kein Exposed Host, sondern sitzt hinter einer FW.

Und an Duplicate Hänk: NAT geht hier doch, genau so wie ich es mir vorgestellt habe. Ohne Portnummer komme ich auf die native NAS, mit Portnummern aud den Container. Ob ich das durchleite muss ich natürlich am Router einstellen, und den mach ich nur auf wenn, es nötig ist.

Hallo Paul,

schön zu lesen dass es auch Leidensgenossen gibt

Ich habe bei mir aus Sicherheitsgründen die automatische Portweiterleitung ausgeschaltet, und die benötigten Ports manuell geöffnet. Ich werde wohl auch mal probieren, ob HOST anstatt NAS als Netzwerkkonfiguration externen Zugriff auf den Container erlaubt - wenn ich das richtig verstehe müsste dann der Container wie eine eigene physischen Maschine im Netz auftauchen und von der Fritzbox eine separate IP bekommen. Wenn ich damit Erfolg habe werde ich berichten.

Das ganze Docker Gedöns ist ja super von der Idee her, aber wie ich schon vor der Beschäftigung damit befürchtet habe liegt die Komplexität in den Schnittstellen. Und gerade weil ich gehofft habe mit den QNAP Oberflächen mir die etwas tiefere Kenntnis von Linux ersparen zu können sehe ich jetzt, dass das alles eben doch gelernt werden muss. Gleiches gilt übrigens auch für phpmail - das funktioniert auch nicht in meinem Container. Das kann ich in Joomla zwar auch direkt über SMTP konfigurieren, aber es wäre eben schön wenn das auch aus dem Container ginge, nur ist das wie alle einzelnen Punkte wieder mit stundenlangem googeln und vermutlich wieder dem unleidigen Installieren von Erweiterungen verbunden.

Ergo: Bis die Docker-Container das machen was man will und sich wie eine native Maschine verhalten ist es halt doch ein langer, zäher und sehr komplizierter Weg!

Setup

• QNAP TS 251+
• Image: Joomla 3.9.1-php7.2-apache
• Ziel: Aktuelle Joomla Version mit php7.2 und nativer Datenbank auf Host betrieben sowie Mapping von /var/www/html auf Host-Verzeichnis und individueller zusätzlicher Konfiguration von php und Apache mit internem und externem Zugriff

Problem 1: Kein externer Zugriff

Ich betreibe die NAS mit internem und externem Zugriff durch Portfreigabe in der FritzBox als Entwicklungsumgebung, der Zugriff erfolgt von außen über QNAPKENNUNG.myqnapcloud.com. Das funktioniert auch hervorragend für alle native Apps (Admin-UI, Filestation, Photostation ect.), aber nicht für den gestarteten Container. Die NAT-Portmappings 8100:80 und 8101:443 sind eingetragen, so dass ich zwar im internen Netzwerk über http://NASNAME:8100 problemlos zugreifen kann, aber wenn ich versuche von außen über http://QNAPKENNUNG.myqnapcloud.com:8100 zuzugreifen, kommt nach Timeout nur eine Fehlermeldung. Mit dem Container ist auch automatischer ein virtueller Switch eingerichtet worden und ich bin davon ausgegangen, dass dieser dafür sorgt, dass auch externe Aufrufe an den laufenden Container weitergegeben werden, aber das scheint nicht der Fall zu sein.

Fragen:

• Funktioniert eine externer Zugriff generell mit NAT oder muss ich ein HOST oder BRIDGE Mapping einrichten (und damit auch separate Portweiterleitung)?
• Wenn ja: Wie muss den Container und/oder ggf. der virtuelle Switch konfiguriert sein, damit externe Zugriff gleich wie interner funktioniert?

Problem 2: php- und Apach-Konfigurationsdateien ganz oder gar nicht

So wie ich diverse Tutorial verstanden habe, sollte die im Container laufende php/Apache Umgebung folgendermaßen konfiguriert werden können (am Beispiel php):

1. PHP startet im Container und liest die im Container vorhandene Standard-php.ini
2. Die gegebene PHP Konfiguration --with-config-file-scan-dir=/etc/config/php.d veranlasst php im Verzeichnis /etc/config/php.d nach zusätzlichen *.ini Dateien zu suchen
3. Dort vorhandene gültige INI-EInstellungen überschrieben die Werte der Standard-php.ini

Ich habe den Container so eingerichtet, dass das Container-Share /usr/local/etc/php/conf.d auf das Host Share /share/php7-apache/config/php/conf.d gemappt wird und dort eine Datei custom.ini enthalten ist, die spezifische Einstellungen enthält. Allerdings funktioniert der oben beschriebene Ablauf nicht, denn sobald ich den Container mit dem Mapping starte, erwartet PHP offenbar, dass alle Konfigurationsdateien darin enthalten sein müssen, also auch die Standard php.ini und alle Erweiterungen, damit sind immer alle Werte aus Local value und Master value identisch. D.h. das selektive Laden bestimmter Einstellungen funktioniert nicht, entweder muss alles aus dem Container kommen (kein Konfig-Mapping zum Host) oder alles wird von außen gelesen (aus bestehendem Konfig-Mapping zum Host), aber selektiv mit z.B. einer einzigen Datei custom.ini, die nur die vom Standard abweichenden Einstellungen enthält klappt nicht.

Fragen:

• Wie kann ich erreichen, dass alle notwendigen Standardkonfigurationsdateien (inklusive Erweiterungen) aus dem Container gelesen werden und nur spezifische Einstellungen aus einer custom.ini?

Vermutlich sind beides wieder super einfache Anfängerprobleme, aber trotz vieler gelesener Tutorials und Dokus ist es mir in 3 Wochen nicht gelungen, das Ganze wie oben beschrieben zum Laufen zu bringen, also ist mir jeder Tipp willkommen.

Ja, genau das hatte ich gehofft zu vermeiden

Hallo tuxflo, doch, das Konzept habe ich schon verstanden.

Ich habe jetzt auch das Basisimage (php7-apache) um PDO "eweitert", also die Extension installiert, aber das geht eben nur mit einem eigenen Dockerfile auf dessen Basis dann ein um die Extensions erweitertertes Image verfügbar gemacht wird. Da ist eben die Implementierung in der Containerstation, sagen wir mal, lückenhaft - wenigstens wenn man wie ich angenommen hat um SSH herumzukommen.

Hallo alle,

nach zwei Wochen erfolgloser Suche versuche ich es hier noch einmal: Wie können Erweiterungen von Images auf einer QNAP NAS realisiert werden?

Mittlerweile erlaubt ja die Dockerstation auch bei Erstellen > Applikation die Eingabe einer YAML Datei - so weit, so gut. Das ist insofern auch ganz gut implementiert, als auch eine Validierung vor Anwendung geht und einem das schmerzhafte trial & error auf putty erspart.

ABER: Offenbar gibt es nach wie vor keinen Weg über diese YAML Dateien Erweiterungen der Images zu installieren. Man kann zwar Zeilen mit COMMAND: <Befehl> integrieren, aber die werden von der Containerstation beim Start an den Container übergeben und der kann damit nix anfangen.

Mein (vermutlich lächerlich einfaches) Problem ist, dass ich PHP auf der aktuellsten Version entwickeln muss. Sollte je eigentlich mit einem Container auf Basis von php-latest oder php:7-apache machbar sein und ist es auch. Allerdings kommen dieses offizielle Images ohne die Erweiterungen mysqli und PDO, was mir auch völlig unverständlich ist, aber egal. Diese Erweiterungen lassen sich aber später nicht installieren, denn der so laufende Container hat keine PHP Oberfläche bzw. der php:7-apache hat eine, aber die gibt nur den Webserver weiter und sobald man z.B. in die Shell gehen will wird der Container wegen SIGWINCH gestoppt.

Die klassichen DOCKERFILEs lt. Docker Dokumentation kann man allerdings mit der Containerstation nicht verwenden - ich wüsste nicht wo. Und die standardmäßig angelegten Verzeichnisse unterhalb der Containerstation (Container > containerstation-data > lib > docker) sind für den Zugriff auch als admin mit allen Rechten gesperrt, und dort müssten ja die Dockerfiles hin.

Also entweder verstehe ich das Ganze nicht oder die Containerstation ist halt auch wieder mal eine halbgare Implementierung durch QNAP.

Hat jemand dazu einen Lösungsvorschlag?

Hallo RocKay,

nein, TS-239 Pro II kann keine Containerstation. Habe auch eine und wollte endlich mit aktuellem PHP7 arbeiten, aber das geht nur in Containern (theoretisch) und die erfordern bessere Prozessorleistung und mehr RAM als die 239 bieten kann.

Ich habe mir deshalb eine TS-251+ mit 8GB RAM besorgt, die hat die Containerstation. Technisch läuft die gut, aber Docker ist ein wahrer Albtraum. Dokumentation von QNAP ist absolut mangelhaft, und viele Images brauchen Erweiterungen, die man nicht installieren kann. Wenn man das also wirklich verwenden will bleibt nur alles zu Fuß über SSH-Konsole zu machen und Linux und Docker mit allem komplett zu lernen. Absolut grauenhaft...

So, jetzt geht's wieder!

Zitat von D.Kampf

Das liegt an der erweitern Freigabe

Verändere die dortigen Einstellungen und stell es danach wieder wie es vorher war.

D. Kampf: Dein Tipp war der richtige, vielen Dank!

Ich habe einfach "Erweiterte Ordnerzugriffsrechte aktivieren" ausgeschaltet - und das war's. Ich habe sie auch gar nicht mehr eingeschaltet, denn ich brauche sie nicht - man merkt u.A. das neben dem jetzt korrekten Zugriff auch das gesamte Handling viel schneller reagiert als vorher.

Mein Denkfehler war anzunehmen, dass man die erweiterten Ordnerzugriffsrechte aktivieren müsse, wenn man eine logische Freigabe erstellt, die physikalisch ein Unterordner z.B. auf Stammebene darstellt. Das ist aber nicht der Fall. Aber ganz offensichtlich verhaspelt sich die NAS mit diesen erweiterten Ordnerzugriffsrechten, das kann ja auch beliebig kompliziert werden.

Zitat von RedDiabolo

PS.: Ich nehme immer den physischen Weg bei der Freigabe, so wie er bei der Berechtigung für die Freigabeordner zu sehen ist.
Wobei es egal ist, ob du den Link der Freigabe, oder den physischen Ordner berechtigst, das wird sofort in der anderen Darstellung auch angezeigt, bzw. übernommen.

ABER, wenn du nur den Link (Freigabeordner) frei gibst, weist du nicht, welcher Ordner darüber sitzt und möglicherweise eine Zugriffsverweigerung hat (die Vorrang hätte).
Hier in diesem Testbeispiel müssten wir zuerst den Ordner Public/Test1/ checken, erst dann wird es interessant, für wen der Ordner Test2/Test3 freigegeben ist. Das sehe ich aber in der Freigabe (Link) nicht, da schaut es aus, als ob der Ordner Test2/ bereits oberster Ordner ist und keine andere Berechtigung über ihn Priorität hat!

Nun, das kann man zwar machen, aber wenn man das müsste, dann wäre der Sinn und Zweck von logischen Freigaben nicht mehr da. D.h. eine logische Freigabe DARF JA GAR NICHT die Berechtigungen der physikalisch darüber liegenden Ebenen übernehmen, denn dann müsste der Admin ja die gesamte Rechtesituation über alle Gruppen hinweg in der Hierarchie im Kopf haben...
Außerdem: Wo ist das Problem mit der physikalischen Location einer logischen Freigabe? Im Eigenschaften-Dialog einer Freigabe finde ich jederzeit deren physikalischen Speicherort:
Zugriffe-Folder1.JPG

Natürlich muss ich meine logische Freigabe Hörbücher nicht so nennen, ich könnte sie auch AudioBooks oder Digitalbuch etc. nennen.

Also ich schließe daraus:

• Ich werde weiterhin physikalische Ordnerhierarchien halten, die mir das Verwalten erleichtern, also z.B.
  
  
  • \Multimedia
    
    
    • \Musik
    • \Audiobooks
    • \Bilder
    • \Videos
    • ...
• Ich werde weiterhin logische Freigaben einrichten, die physikalisch auf bestimmte dieser Unterordner zeigen
• Ich werde ausschließlich gruppenbezogen Rechte vergeben, d.h. bestimmten Benutzergruppen definierte Zugriffsrechte auf die logischen Freigaben einrichten (und wenn möglich werde ich mir die Gruppen überschneidungsfrei halten, denn die Rechteprioritäten bei Überschneidungen nachzuvollziehen kann eine echte Herausforderung sein
• Der Rechtevorschau der NAS kann man nicht trauen, sie zeigt (zumindest bei aktivierten erweiterten Ordnerzugriffsrechten) schlichtweg falsche Ergebnisse an
• Für alles oben gesagte brauche ich die erweiterten Ordnerzugriffsrechte nicht, also kann ich sie abgeschaltet lassen.

Und: Ich prüfe alles lieber vorher. Es ist ja gut, dass die NAS lieber restriktiver als zu großzügig damit umgeht.

Zitat von RedDiabolo

Alle anderen Ordner, die unter Multimedia/ liegen und auf die der Hörbuch-Benutzer nicht zugreifen darf, musst du explizit pro Benutzer sperren.
Ein Sperre auf die oberste Freigabe (Multimedia/) sperrt alles darunter, egal wenn oder was du darunter freigeben willst ...

Ich glaube, das ist nicht richtig so, und ich bin mir sicher es darf so nicht sein. Denn dann müsste ich ja ggf. hunderte von Berechtigungen setzen, und genau über das verliert man die Kontrolle und das ist bei der Rechtevergabe am Ende ein echtes Sicherheitsrisiko.

Danke an alle für die Diskussion

Hallo RedDiabolo,

danke für Deine Ausführungen un Beispiele. Im Prinzip habe ich das alles schon verstanden, nur sind zwei Dinge fragwürdig:

• Physikalische oder logische Priorität?
  Was ist priorisiert, die logische Freigabe oder die physikalsiche Ordnerhierarchie und die aus oberhalb liegenden Ordnern abgeleitete Rechtesetzung? In Deinem Beispiel ist die Freigabe Test2 ja ein physikalischer Unterorder von Test1. Wenn jetzt die Rechte von Test1 (physikalisch) und Test2 (logisch) kollidieren - wer gewinnt?
• Änderung
  Tatsächlich habe ich den Freigabeordner Multimedia mit den Unterordnern \Music und \Hörbücher, beide auch als logische Freigabe eingerichtet, auf die eine betreffende Benutzergruppe Zugriff hat. D.h. diese Gruppe darf RO auf Music und Hörbücher zugreifen, aber nicht auf den gesamten Multimedia Ordner. Das wäre so eine Konfliktsituation.
  Nur ist es nicht nachvollziehbar, dass
  
  • Diese Konstellation seit 4 Jahren wunschgemäß funktioniert hat - und jetzt nicht mehr
  • das so sei sollte, denn dann wären logische Freigaben quasi irrelevant und jede Freigabe müsste auf höchster Ebene überschneidungsfrei und benutzergruppenspezifisch eingerichtet werden- und damit wäre die gesamte spezifische Rechteverwaltung sinnlos. Außerdem gehöre ich selbst ja zwangsweise auch der Gruppe everyone an (die keinen Zugriff hat), d.h. auch ich müsste denn den Zugriff verweigert bekommen, das ist aber nicht der Fall. Und die Rechtevorschau, sowohl auf Gruppen- als auch auf Personenebene, zeigt genau die Rechte an, die ich eigentlich habe möchte, nur die NAS verhält sich nicht so.

Hallo Mavalok2,
danke für die Antwort.

- Zu 1: Ich habe das Verhalten selbst mit Windows 7 Professional und mit Windows 8 auf drei verschiedenen Rechnern getestet, überall dasselbe Verhalten. Ich kann nicht genau sagen, welche anderen OS andere Benutzer verwenden, gehe aber davon aus dass alle Windows-OS sind (7 und höher)
- Zu 2: Firmware-Version 4.2.6 Build 20171026
- Zu 3: Über QNAP Filemanager. Bei mir selbst auch über verbundene Laufwerke, die auf \\servername\Freigabename gemappt sind, aber bei mir funktioniert alles korrekt und ich habe Zugriff auf alle Shares.

Ein Screenshot von einem Beispiel im Anhang: Beispielbenutzer Dieter_Hoffmann ist angemeldet, bekommt im FileManager die Freigabeordner "Music" und "Hörbücher" angezeigt (wie es auch sein soll, seine Benutzergruppe hat RO Access), aber es erscheint die Meldung "Zugriff verweigert". Das an sich kann doch schon nicht sein, denn wenn er keine Zugriff haben sollte (lt. Rechtevergabe), dann dürfte FileManager ja den Freigabeordner schon gar nicht anzeigen!

Und dort wo Benutzer erratisch Zugriff bekommen und ein File herunterladen wollen, hat es danach die Größe 0 Byte.

Hallo,

habe bisher nur einen, allerdings unbeantworteten Artikel zum Problem gefunden, ggf. gibt es aber dazu schon Lösungen, die ich nicht gefunden habe.

Meine NAS TS239 Pro II+ hat einige Benutzer in einer Benutzergruppe A, die in Read-Only Modus auf zwei Freigabeordner zugreifen können sollen. Meldet sich ein solcher Benutzer an, bekommt er im FileManager auch die Freigabeordner links oben angezeigt, aber wenn er draufklickt erschient die Meldung "Kein Zugriff". Es sind keine einzelnen Zugriffsrechte für einzelne Benutzer erteilt worden, alle Rechtevergabe gehen über Gruppen.

Eine andere Benutzergruppe B bekommt zwar Zugriff auf einen zugelassenen (hier R/W) Freigabeordner, aber beim Versuch eine Datei herunterzuladen ist die Dateigröße immer 0 Byte, also unbrauchbar. Gruppe B hat ebenfalls RO-Zugriff auf die oben genannten , exakt gleich definierten Freigabeordner, von denen auf einen zugegriffen werden kann, auf den anderen aber nicht.
Ich habe schon die entsprechenden Benutzer gelöscht und neu angelegt, die Gruppen gelöscht und neu angelegt und die Rechtevergabe bestätigt, bzw. wiederholt, rebootet etc. aber alles ohne Erfolg - dis NAS verhält sich nicht so wie sie soll, d.h. das gesamte Rechtemanagement ist im Eimer.

Soeit ich bisher gegoogelt habe, bleibt nur ein Neuaufsetzen des Systems, oder hat jemand eine andere Idee?

Hallo zusammen,

gibt es eigentlich irgendjemanden, bei dem der Ausschlussfilter

/.@__thumb

schon mal tatsächlich funktioniert hätte?

Ich habe das auf TS-239 Pro II+ mit QTS 4.1.3 nun in allen möglichen Variationen bei einem Backupjob auf eine per UNC addressierte zweite NAS probiert, mit und ohne Slash, mit und ohne Joker, im globalen - oder Job-sprzifischen Filter etc. etc.

Support sagt, er habe "keine Anleitung" und weiß selbst nicht wie's geht. Das betrifft natürlich nicht nur .@__thumb, sondern alle folder, die mit . beginnen, da gibt es bei mir noch ein paar.

Wenn jemand tatsächlich einen Filter zum Funktionieren gebracht hatte postet das doch bitte noch einmal, bei mir werden die Filter schlicht ignoriert.

Gruß OUtsch