Samba und die Unix CIFS-Extensions

Ich wollte mal was zu Samba loswerden, wovon vielleicht auch der eine oder andere Windows-Admin profitiert. Ich bin ebenfalls ein Solcher. Wir nutzen Samba seit Jahren auf Basis von Univention Corporater Server (http://www.univention.de/produkte/ucs/ucs-komponenten/dateidienste-und- ..), weil hier besonders einfach grafisch, webbasiert konfigurierbar. Dazu möchte ich zum Ende dieses Beitrages noch was sagen. UCS ist aber nicht Thema dieses Beitrages, sondern Samba (File-Services) an sich und zwar diesmal die Client-Seite. Hier habe ich mich selbst mit dem Verständnis grundlegender Zusammenhänge lange schwer getan unter anderem ein Grund, sich bei dem Setzen von Zugriffberechtigungen bei der grafischen Samba-Administration von Unvention Corporate Server zu bedienen. Trotzdem sollten auch Gelegenheits-Samba-Nutzer Folgendes wissen:

Wenn auf Server-Seite die cifs-Unix-Erweiterungen aktiv sind (was auf der Server-seitigen samba.conf durch den Eintrag unix extensions = yes gewährleistet ist und der Default-Einstellung entspricht), überträgt Samba die „echten“ Eigentums- und Zugriffsrechte zwischen Server und Client. Das hat weitreichende Folgen. Ändert z. B. ein Nutzer auf dem Client Rechte mit chmod oder chown oder mit Hilfe des Eigenschaften-Dialogs von Dolphin oder Nautilus, wirkt sich die Änderung unmittelbar auch auf den Server und indirekt auch auf allen weiteren Clients aus, die auf diese Freigabe zugreifen möchten. Das klappt natürlich nur, wenn der entsprechende Nutzer, der die Rechte einer Freigabe ändern will, in dieser auf dem Server überhaupt Schreibrechte hat. Diese UNIX-Erweiterungen haben immer Vorrang vor anderen Eigentums- und Zugriffsrechte, die eventuell beim Mounten in /etc/fstab des Clients oder beim manuellen Mounten auf dem Client per Parameter angegeben werden. Die werden dann nämlich ignoriert. Das Synchronisieren der Rechte erfolgt durch das Übertragen von uid, gid, dir_mode und file_mode, funktioniert aber nur dann korrekt, wenn die Benutzer auf dem Server und dem Client die gleiche Benutzerkennung (UID) und Gruppenkennung (GID) besitzen, was ggf. entsprechend angepasst werden muss. Einschränkungen kommen noch dazu, wenn auf dem Samba-Server kein Linux-Dateisystem, sondern NTFS oder gar FAT zum Einsatz käme, was ja immerhin möglich ist, weil der Linux-Server selbst ja solche Partitionen lesen/schreiben, bzw. mounten kann. Dann wird die Wirksamkeit der CIFS-UNIX-Erweiterungen natürlich durch da jeweilige Dateisysteme eingeschränkt. Allerdings sollte man von solchen kruden Konstruktionen ohnehin eher die Finger lassen. Jedenfalls ist es dann zunehmend schwieriger vorauszusgen, wie sich dann Samba verhält.

Unterstützt der Server die cifs-Unix-Erweiterungen nicht, weil er entweder ein Windows-Server ist oder weil in der Samba-Config auf dem Server unix extensions = no gesetzt ist, wozu es ebenfalls gute Gründe geben kann, müssen die Zugriffsrechte „simuliert“ werden. Verwendet man dann mount.cifs bekommt die Freigabe den Besitzer, der sie gemountet hat. Etwaige Schreibrechte werden dann auch auf diesen übertragen. Das geht, weil das Mounten an sich ja nur mit Root-Rechten oder über die /etc/fstab möglich ist. In der Regel hat man dann also Root-Schreibrechte. Diese lassen sich aber wieder durch ergänzende Angaben beim Mounten mit uid, gid, file_mode und dir_mode weiter einschränken, bzw. explizit festlegen.
Sind die Unix-Extensions auf dem Server aktiv, weil es sich z.B. um ein NAS-System handelt, zu dem man evtl. keinen Root-Zugang hat, aber man will sie nicht, kann man sie auch beim Mounten unterdrücken, bzw. das Ignorieren erzwingen. Das ist jetzt der exakt umgekehrte Fall, wie oben beschrieben. Dann bietet es sich an, die Mount-Option nounix zu benutzen. Damit werden die Unix-Extensions deaktiviert, sodass sie angegeben Optionen für uid, gid, file_mode usw. wieder wie gewünscht greifen. Übrigens bleiben mit nounix Eigentums- und Zugriffsrechte auch bei einem Backup unberücksichtigt, was manchmal gewünscht sein kann.

Apropos: Sind die Unix-Extensions aktiv sind, sollte man Gast-Zugriffe unbedingt vermeiden, weil dann der Zugriff auf neu angelegte Dateien und Ordner nicht mehr funktioniert, da diese dann nobody gehören. Ist das trotzdem passiert und man schaltet beim Mounten die Unix-Extensions mit nounix ab, kann man z. B. file_mode=0666 und dir_mode=0777 setzen, wodurch durch nobody angelegte Dateien und Ordner wieder lesbar sind.
Jetzt zurück zum Univention Corporate Server. An dem gefällt mir, dass man im umfangreichen grafischen Dialog bequem im Browser mit den Samba-Einstellungen experimentieren kann. Hauptgrund, UCS als Samba-Server einzusetzen ist für uns allerdings Samba 4. So ersetzt unser UCS einen betagten MS Server 2003, dessen Support ab nächsten Monat ausläuft, jetzt zuverlässig als Domänencontroller.