Samba Berechtigungen offensichtlich zerschossen

Hallo Liebe QNAP-Profis,

die Forensuche brachte leider keine brauchbaren Ergebnisse (vielleicht falsch gesucht, vielleicht gab es das aber auch noch nicht), deshalb dieser neue Thread.

Ich bin mit einem TS453Pro mit (leider) QTS 4.2.0 eingestiegen und hatte erhebliche Performanceprobleme. Diese Probleme wurden durch die 4.2.1, welche ich zunächst als Beta verwendet und seit ein paar Tagen als offizielle Release installiert habe, gelöst. Leider muckt Samba noch rum.

Ausgangssituation: am QNAP hängen mehrere Win 7 PCs, auf dem QNAP ist der Domain Controller aktiviert, Usergruppen sind angelegt, User (10 Stück) sind angelegt und verschiedenen Gruppen zugeordnet. Die Win-Benutzerprofile werden in entsprechende Verzeichnisse gepackt. Es sind Freigabeordner angelegt, die die Win-Workstations selbst als Netzlaufwerk verknüpft haben. Grundsätzlich funktioniert mal alles.

Aber: Es gibt Probleme mit den Berechtigungen. Wenn ich z.B. für einen Freigabeordner eine Gruppe als Berechtigung hinzufüge, kann es sein, dass einige User der Gruppe keinen Zugriff erhalten. Auf eine andere Freigabe können sie aber über die gleiche Gruppenberechtigung zugreifen.
Es kann vorkommen, dass wenn ich die Berechtigungen gesetzt und dann auf "Übernehmen" geklickt habe, die gesetzten Berechtigungen verschwinden.
Es gibt Freigabeordner, da erscheint die gleiche Berechtigung in mehreren Zeilen doppelt und dreifach.
Es gibt Freigabeordnar, da ist das Gastzugriffsrecht "-1" und es lässt sich nicht ändern und speichern.

Zusammengefasst: in den Freigaben ist total der Wurm drin. Auf meinem alten Linux-Server hätte ich jetzt die Kommandozeile gestartet und mir die samba.conf angeschaut. Beim NAS habe ich noch keine Kommandozeile gefunden. Dafür habe ich immer fleißig ein Backup der Domänen-Einstellungen gemacht, allerdings offensichtlich schon immer mit zerschossenen Daten. Interessanterweise ändert sich die Größe dieser .exp-Datei erheblich, mal ist sie 2 MB groß, am nächsten Tag 3,5 MB, ohne dass ich etwas verändert habe.

Nun meine Frage: was ist der einfachste und sinnvollste Weg, wieder Ordnung in das Durcheinander zu bringen? Am besten ohne die ganze Kiste komplett neu aufzusetzen. Gibt es eine Chance, diese Backupdatei zu zerlegen, reparieren und wieder einzuspielen? Und falls das nichtz funktionieren sollte, kann ich von irgendwo eine "saubere" Datei bekommen und einspielen, auf die ich dann die Berechtigungen neu aufbauen kann?

Sorry für die vielen Fragen und schon mal Danke für hilfreiche Antworten (oder Nachfragen).

Klaus

Hallo Leute,

ich antworte mir mal selber, da ich inzwischen ohne Hilfe ein bischen weitergekommen bin. Ich habe mir den gesamten etc-ordner per pscp auf meinen PC kopiert und mir die smb.conf angeschaut. Oh welch ein Graus, so chaotisch sah meine händisch "gepflegte" smb.conf auf meinem alten Linux-Server nicht aus. Bei allen möglichen Freigaben stehen Samba-User und Gruppen bei den jeweiligen Berechtigungen doppelt und dreifach drin, die Datei ist dadurch unendlich aufgebläht. Interessant ist, dass das so ist, obwohl ich die Domäne bisher immer nur über die Benutzeroberfläche "bedient" habe. Hier muss also wie angenommen total der Wurm drin gewesen sein.

Da der DC nach einem Crash mit der unausgereiften 4.2.0 mal nicht mehr tat, hatte ich mich getraut, das DC-Backup zurückzuspielen. Da das funktionerte, denke ich, dass mit meinen Editier-Versuchen eigentlich nichts verschlimmern kann, denn es gibt ja ein Backup. Ich bin allerdings nicht so ganz sattelfest und weiß nicht, wo eigentlich die Zuordnungen der User in die Gruppen zu finden sind, denn ich möchte mir auch diese anschauen (vielleicht kann mir jemand einen Tipp geben).
Wenn alles nichts hilft, würde ich sogar einen jungfräulichen "leeren" Domaincontroller einspielen wollen und sämtliche Freigaben neu erstellen (ich hoffe, die Daten bleiben erhalten, es gäbe aber ein Backup). Wo bekomme ich "leere" Daten her, ohne alles platt machen zu müssen?

Seit der 4.2.1 beta läuft das NAS zwar inzwischen stabil, aber extrem zäh. Deswegen muss ich was tun.

Danke! Klaus

Hallo Matthias,

ich bin nach allem hin und her fast soweit, den QNAP rauszuwerfen und ein Wettbewerbsprodukt oder wieder einen Linux-PC einzusetzen. Eine Galgenfrist bekommt die Kiste noch, ich werde mir eine externe "dicke" HDD holen, alle Daten rüberspielen (ich mache sonst nur Online-Backup, das komplette Zurückspielen würde mir zu lange dauern) und die ganze Kiste in den Ursprungszustand zurücksetzen (in der Hoffnung, dass es dann wirklich ein "sauberes" System gibt) und neu aufsetzen. Ich habe die Kiste ja auf der 4.2.0 aufgesetzt, die sich bekanntlich als hochgradig fehlerhaft herausgestellt hat.

Das ist wie gesagt die letzte Chance für das Teil. Leider waren weder dieses Forum, noch der QNAP-Support wirklich hilfreich. Die ganze Kiste ist mir auch irgendwie zu undurchsichtig. An meinem alten Linux-Server-PC wusste ich, wo ich was finde, wie ich da hinkomme und die Einstellungen ggf. per Editor oder Kommandozeile vornehme. Ebenso war die nutzbare Performance des inzwischen deutlich über 12 Jahre alten PCs als DC um Längen besser als die QNAP-Kiste momentan läuft (hatte zwar nur 1x 100 MBit/s, aber deutlich geringere Latenzzeiten!). Ich hatte die Platten im RAID allerdings auch mit einem anderen Filesystem formatiert, bei QNAP kann ich ja leider nur ext3 oder ext4 wählen. Und das verursacht ja offensichtlich (so steht es zumindest in einem englischsprachigen Forum) bei einer großen Anzahl an Dateien mächtig Latenzzeit. Wenn man aber einen DC hat und auch die Windows-Benutzerprofile zentral speichert, kommen nun mal viele Dateien zusammen. Und dann bringen mir gebündelte Gigabit-LAN-Ports auch nichts, wenn ich bei jeder Datei erst mal eine Gedenksekunde habe. Wenn das Mainboard des alten Servers nicht inzwischen das Handtuch geworfen hätte, wäre der schon wieder statt des QNAP im Einsatz.

Natürlich habe ich für verschiedene Arbeitsbereiche einzelne Freigaben gemacht, die ich einzeln als Netzlaufwerk anspreche (wie beim alten Linux-Server...), aber das bringt es auch nicht.

Ja das mit dem smb.conf hatte mich auch gewundert. Es gibt noch einen Unterordner "config", in dem scheint eine Kopie der smb.conf zu liegen. Ich hatte meine smb.conf per Editor aufgeräumt und dann beide überschrieben. Dann hatte ich zumindest in der Freigabeoberfläche keine Phantomeinträge mehr, die ich nicht löschen konnte.

Wundern tut mich, dass ich nahezu täglich eine Fehlermeldung beim Backup der DC-Einstellungen bekomme: "file changed as we read it". Sollte eigentlich auch nicht sein denke ich.

Sorry, wenn ich dir keine bessere Antwort geben kann. Ich melde mich aber, wenn ich irgendwie weitergekommen bin.

Grüße, Klaus

Mal ein Update zwischendurch: Ich habe einen NTFS-formatierten USB-Stick an das NAS angeschlossen und versuchte verzweifelt eine Freigabe zu erstellen, konnte den Stick aber nicht als Laufwerk auswählen. Zufällig fand ich den dann schon zwischen den Freigabeordnern, also eine einzige Freigabe für mich als DomainUser erstellt.
Leider ist die Zugriffszeit auch auf den Stick unterirdisch, kein Unterschied zu den HDDs bzw. SSDs feststellbar. Wenn ich ein CAD-File speichere geht das etwa 15 Sekunden. Speichere ich lokal, dann rennt der Fortschrittsbalken in nicht mal einer Sekunde durch (ist aber bei anderen Files auch so, das CAD ist nicht das Problem). Das Problem liegt also offensichtlich nicht an der Formatierung der internen HDDs/SSDs.

Klaus

Wenn ich eine größere Datei kopiere, dann bin ich geschwindigkeitsmäßig auch bei dem, was das Gigabit-Lan hergeben kann. Wenn ich allerdings viele kleinere Dateien kopiere, dann kann ich die Inhalte der Dateien fast mitlesen, so langsam geht das. Und das ist von allen Win7-Rechnern (und noch 2x XP) so, und selbst von meinem Android-Smartphone die gleichen Probleme.

Vor allem habe ich zwischendurch immer mal wieder Meldungen wie "darf nicht zugreifen" usw., die Dateien werden aber oft trotzdem kopiert/geschrieben. Manchmal muss man einen 2. Versuch starten, der dann meistens klappt.

Ja so einen merkwürdigen Effekt mit wohl plötzlich verschwindenden Rechten, die dann aber auch wieder da sind, habe ich auch. Es kann sein, dass ich beim Speichern einer Datei kein Zugriffsrecht habe, beim nächsten Versuch (sofort danach) klappt es dann.
Manchmal wird es ganz schlimm, dann fangen die Netzlaufwerke im Windows-Explorer an bunt zu blinken (rot/grün). Das ist dann der Zeitpunkt für einen Neustart.

Ezekiel666: mir ist klar, dass für jede einzelne Datei zunächst die Berechtigung geprüft werden muss und sich viele kleine Dateien langsamer kopieren als eine große. Die Frage ist nur, wie viele (Milli-) Sekunden es jedes Mal für das Prüfen der Berechtigung brauchen darf.
Wärst du so nett, einem noch nicht so QNAP-Erfahrenem ein paar "andere Ursachen" aufzuzählen?

Ein kleines Update zwischendurch: Das Durchforsten der Fehlerprotokolle der Workstations hat mich darauf gebracht, dass die Gruppenrichtlinien nicht erreichbar sind. Die sollten eigentlich auf dem NAS unter "sysvol" liegen, laut Filestation ist der Ordner aber leer. Habe mich per Putty dort hingewühlt (der Pfad passt zum EIntrag in der smb.conf), aber auch hier alles leer. Gibt es irgendwo ein "Versteck" für die Daten? Kann man die irgendwo herzaubern?

Mein nächster Schritt wäre, den DC irgendwie zu löschen und komplett neu aufzusetzen.

Zitat von Araneus

Nur so war es uns z.B. auch möglich, das Ablaufen von Passwörtern zu deaktivieren - alle Einstellungen auf dem QNAP dazu schienen keinen Effekt zu haben.

So einen Effekt habe ich bei zwei Workstations auch (interessanterweise an den anderen nicht). Ich hoffe mit den Gruppenrichtlinien auf dem richtigen Weg zu sein und hoffe noch mehr, dass die Latenzzeiten dann auch deutlich geringer werden.
Traurig, dass es sich bei mir nicht um einen Einzelfall zu handeln scheint. Mein Vertrauen in QNAP schwindet mehr und mehr. Schade, dass die QNAP-Software so fehlerhaft ist.

So, ich scheine die Probleme gelöst zu haben. Allerdings tatsächlich nur mit der harten Tour und einem Wochenende ohne vor die Tür gegangen zu sein. Hier eine Zusammenfassung, damit User mit dem gleichen Problem nicht in Fallen tappen. "Erfahrung" sind Dinge, die ich nächstes Mal anders machen würde.

Habe mir sämtliche Daten auf eine externe Festplatte gezogen (per "File Station" auf eine Platte direkt am NAS). WICHTIG: danach die Platte vom NAS abziehen (ohne Abziehen scheinen einige User sehr schlechte Erfahrungen gemacht zu haben).
Absolut lebensnotwendige Daten habe ich noch einmal auf einen Client kopiert, so dass wir im Extremfall kurzfristig per Freigabe hätten weiterarbeiten können (zurückspielen vom Onlinebackup braucht ewig).
Die beiden VMs gesichert ("VM sichern & wiederherstellen"). Erfahrung: Die Daten auf den VMs unbedingt noch einmal separat von der Maschine aus sichern und sich nicht auf die Abbilder verlassen!

Erfahrung: Die einzelnen Windows-Benutzerprofile lokal an den Clients per "Easytransfer" auf einen USB-Stick oder eine HDD sichern. Später kommt man da so leicht nicht mehr dran! Vorher schauen, dass die wichtigen Daten da auch tatsächlich drin sind!
Erfahrung: Die Clients aus der alten Domäne entfernen und in irgendeine "Workgroup" stellen. Aus der Domäne entfernen wenn die Domäne nicht mehr da ist kann problematisch sein.

NAS Firmware war aktuell (4.2.1 2016/07/05).

"NAS neu initialisieren" gewählt. NAS heruntergefahren, HDDs gezogen.

NAS eingeschaltet und die absoluten Grundeinstellungen durchgeführt (Kennwort, IP-Adr. usw.).

HDDs gesteckt und die beiden RAID 1 Laufwerke eingerichtet je als (Einzellaufwerk), EXT4 formatiert.

Domain Controller neu eingerichtet. Erfahrung: die Domäne sollte einen anderen Namen als vorher haben, sonst geistern in den Workstations alte Settings rum. Es geht definitiv nicht, die Domäne gleich zu nennen und zu hoffen, man könnte dann wieder mit Windows drauf zugreifen.

Zuerst die Usergruppen eingerichtet (auch eine Gruppe "Client-Admin"). Dann die Freigabeordner erstellt (Freigaben nur per Gruppen). Dann die User angelegt, zu den Gruppen hinzugefügt und Profilpfad und Home-Verzeichnis eingestellt.
Zurückspielen der Daten in die Freigaben gestartet.

Nun an den ersten Client (Win 7) und diesen zur Domäne hinzugefügt. Neustart, neu anmelden als User klappte. Abmelden und als Domain-Admininstrator angemeldet.
In der Verwaltung die Gruppe "Client-Admin" zu der Administratorengruppe hinzugefügt. So kann ich über die Gruppenzugehörigkeit der Domäne festlegen, wer an seinem PC schrauben darf.
Das Benutzerprofil per Easytransfer auf den neuen Useraccount (neue Domäne!) zurückgespielt.
Nach der Useranmeldung ist die gewohnte Umgebung wieder da.

Und nun beginnt ein mittelschweres Drama. Ich habe versucht, die VMs zurückzuholen. Erst mal die "Virtualisation Station" installiert. Es gab prompt Probleme mit der Portbündelung (habe zwei LAN-Kabel vom NAS zum Switch). Es war der falsche Bündelungsmodus eingestellt (bei der 4.2.0 hatte ich diese Meldung nicht).
Nun also VM wiederherstellen. VM-Abbilder wurden gefunden, eines ausgewählt und "Verarbeitung sofort nach Übernahme" angehakt. "Übernehmen" angeklickt und das Fenster wird grau und nichts tut sich. Mehrfach probiert, nichts geht.

Nun habe ich einen kleinen Ausflug in Richtung "VM neu Installieren" gemacht und irgendwie versucht, die ebenso gesicherte originale .img-Datei als Festplattenabbild einzubinden, allerdings völlig ohne Erfolg, die VM "bootet" nicht.
Also eine ganz neue VM erzeugt und ein neues Win7 aufgespielt. Natürlich funktioniert die Aktivierung mit dem alten Code nicht. Ebenso habe ich festgestellt, dass mein Datenbank-Backup nicht funktioniert hat oder sich zumindest nicht restoren lässt (muss ich noch checken was da los ist). Dieser Weg war also keine Lösung für mich und ich habe mich tierisch geärgert, dass ich nicht wenigstens ein Backup (und wenn es nur ein Kopieren der Files gewesen wäre) direkt von der VM aus gemacht habe. Ich musste die Sicherung der VM also irgendwie benutzen, aber wie.

Nach langem Probieren habe ich fstgestellt, dann man beim VM Restore wohl keinesfalls "Verarbeitung sofort nach Übernahme" angehakt haben darf und die Rücksicherung auch nur vom externen Laufwerk aus funktioniert (hatte das Abbild schon auf das NAS kopiert, von da aus geht es aber wohl nicht!).
Ergebnis: Die VM mit der Datenbank läuft wieder.

Die ganze Aktion hat vom Freitagnachmittag bis zum Sonntagabend gedauert, zwischendrin gab es nur kurze Nächte. Auch wenn es sehr mühsam war und es viel Wartezeit gab (knapp 2 TB Dateien kopieren geht halt etwas...), hat es sich gelohnt, das System flutscht seit dem. Einzig Subversion ist noch nicht installiert, aber da steige ich ggf. auf eine Alternative um oder ich baue es in die Windows-VM mit ein, die die Firebird-DB hat.

Auf QNAP bin ich trotzdem stinkig, denn nachwievor bin ich der Meinung, dass all die Probleme nur durch die fehlerhafte QTS 4.2.0 verursacht wurden, denn der Unterschied zu meinem ersten Aufsetzen ist nur die QTS-Version. Das letzte Wochenende hätte ich zudem viel besser in der Sonne am See verbringen können. Wenn ich nur einen ganz kleinen Stundenlohn angesetzt hätte, hätte ich ein neues NAS raus (Empfehlung an QNAP).

Ich werde in ein paar Wochen noch mal schreiben, ob noch alles ordentlich läuft und hoffe, dass diese Post vielleicht dem Einen oder Anderen eine Hilfe ist.

Klaus

Noch ein kleines Schmankerl zum Schluss. Gelegentlich hatte ich noch die Fehlermeldung, dass ich die IP-Einstellungen prüfen soll, da "Hosts" nicht richtig aufgelöst werden. Ebenso kam es zeitweise vor, dass ich wenn ich die FritzBox an den Clients als DNS eintrage die Domäne und Freigaben, wenn ich das NAS als DNS eintrage externe Seiten nicht aufzufinden sind.

Nachdem ich durch die Menüs der Fritzbox gestöbert bin, fiel mir auf, dass die IP vom NAS doppelt auftauchte und ein Eintrag "blockiert" wurde. Offensichtlich eine doppelte IP-Vergabe. Ich vergebe die IPs aber eher pedantisch und pflege eine Liste, so dass das nicht vorkommen sollte.

Ich hatte zunächst den "Virtual Switch" in Verdacht und habe den auf einen anderen LAN-Port mit einer anderen Adresse gelegt, allerdings ohne Erfolg.

Eine verzweifelte Google-Suche nach der 192.168.178.201 brachte letzendlich den Hinweis, dass dies wohl die VPN-Default-Tunneladresse der Fritzbox ist. Habe die IP vom NAS auf die ..202 gestellt, die Clients haben die ..202 als primären DNS und die FritzBox als sekundären DNS (in der FB Rebind-Schutz ausgeschaltet) und seit dem läuft alles. Ein VPN habe ich übrigens nicht im Einsatz.

Interessanterweise taucht eine verwendete 192.168.178.201 in der Fritzbox (7362SL, OS 6.50) entweder gar nicht oder doppelt auf. Für mich sieht das nach einem ganz bösen Effekt wenn nicht sogar Bug der Fritzbox aus.

Hoffe, meine Ausführungen helfen jemandem weiter.

Klaus