Vergabe von Rechten für einen Ubuntu Server 20.04 an einer SMB-Share

Ich habe folgende Frage:

Ich betreibe einen Ubuntu Server 20.04, dessen ausschließliche Aufgabe eine SQL-Datenbank unter MSSQL.

Ich möchte von einem Windows 11 mit MSSMS Backups der SQL-Datenbank auf eine SMB-Share erstellen. Die SMB ist auf einer TrueNAS Core. (FreeBSD).

Der Windows-Benutzer, der Ubuntu-Benutzer und der NAS-Benutzer sind identisch.

Ich kann (selbstverständlich) von Windows auf die SMB schreiben.

Auf dem Ubuntu habe ich die SMB-Share \\192.168.2.11\Backups\Backup auf /mnt/smb_share gemountet.

Beim Versuch auf die SMB zu schreiben bekomme ich eine Fehlermeldung, daß ich keine Schreibrechte habe. Die Rechte sind 775.

Lediglich wenn ich mich am Server als root anmelde, kann ich schreiben. Auf der NAS existiert auch ein User root, also weshalb geht es nicht mit einem anderen gleichen User. Ich bin davon ausgegangen, daß vom Ubuntu Server darauf geschrieben werden kann, solange man als gleicher Benutzer wie auf der NAS angemeldet ist.

Wo liegt mein Denkfehler? Danke

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 93463484609

Url: https://administrator.de/contentid/93463484609

Ausgedruckt am: 21.11.2024 um 13:11 Uhr

15 Kommentare

Neuester Kommentar

Der Denkfehler kann sein, dass hosta\root nicht Hostb\root ist.

Aber ohne Details, eine Freitagfrage...

Hallo,
zuerst : hier kein NAS ..aber!
natürlich muss UserID-A gleich Userid-B sein ... sonst ist es ein anderer User (und müsste ggfs angelegt werden) .
Namen sind Schall und Rauch .. numerische Userid muss auf beiden Seiten passen!
Optimalerweise mounted man user "der Backup_User"
Rechte = 775 sind für das Verzeichnis auf welcher Seite ? (A oder B sprich Ubuntu oder NAS)

Wir hatten bis zu 9 Samba-Server zu laufen in verschiedenen Netzen (routed) und peinlich drauf geachtet dass es jede UserID nur einmal und immer auch (blind) auf jedem System gab, zuminderst wenn die Möglichkeit bestand das User x darauf zugreifen könnte.

Es werden wohl alle "roots" immer die gleiche UID haben.... damit geht das!
Mache einen "test"user z.B. mit UID=1234 auf allen beteilgten Systemen und es wird gehen.

Fred

ps: bei ein bis zwei Useränderungen im Monat ist/war das gerade so beherrschbar

Alternativ kann man beim Mount auch UID und GID mitgeben auf den man den Mountpoint mappen möchte und auch forcieren falls nötig. Anzugeben als Options beim Mount

sudo mount -t cifs -o 'username=Bla,password=blub,uid=XXXX,gid=XXXX,forcegid,forceuid' //server/share /mnt/point  

https://linux.die.net/man/8/mount.cifs

Gruß sid.

Danke für Eure Kommentare und bitte habt Geduld mit mir

Meine Kenntnisse in Linux sind absolut rudimentär, aber langsam wird es besser. Ich verstehe was Ihr schreibt. Bloß wo sorge ich dafür, daß beispielsweise root auf der NAS (TrueNAS Core unter FreeBSD) die gleiche Nummer hat wie der Root in der VM (Ubuntu 20.04). Gleiches für den User "ich", den ich unter Windows 10 habe, identisch mit dem User auf der NAS. Denn da mußte ich keine eindeutige Nummer vergeben, denn da melde ich mich von Windows an der SMB-Share user:pass an, wobei meine Windows user:pass gleich dem auf der NAS angelegten Benutzer. Naiverweise ging ich davon aus, daß wenn auf dem Linux Server der gleiche Benutzer ist, daß er an der SMB die gleichen Rechte bekommt wie der gleichnamige Benutzer von Windows. Denn bei Root hat es geklappt: dieser heißt auf der NAS 'root', auf Ubuntue auch 'root' und beide haben das gleiche Passwort. Ich verstehe eben nicht, wieso der 'root' von Ubuntu die auf der NAS definierten Schreibrechte bekommt, der user 'ich' nur wenn er sich von Windows anmeldet. Es wird schon seine Richtigkeit haben, aber ich habe da noch gewissermaßen Begriffprobleme

Ich habe hier folgende UID/GID:

root auf Ubuntu UID=0 GID=0
root auf NAS UID=0 GID=0

user auf Ubuntu UID=1000 GID=1000
user auf NAS UID=1000 GID=1000

Deswegen war ich der Meinung, daß die NAS dem UID=1000 die richtigen Werte gibt.

Eventuell ist es kein Problem des Host-User-Mappings, sondern des Samba-User-Mappings.

Wenn Du den Share auf die Ubuntu-Maschine mountest, machst Du vom Windows aus ein SMB-Mapping dorthin, nicht auf das NAS. Wenn Du im Ubuntu zwar den Linux-User angelegt hast, nicht aber auch den Samba-User (gleichen Namens/PW), versuchst Du auf ein SMB-Share zu mappen, für das keine credentials vorliegen.
https://wiki.ubuntuusers.de/Samba_Server/ :

Bei der Installation von Samba wird leicht vergessen, dass weder die im System eingetragenen Benutzer noch deren Passwörter automatisch in die Benutzer-Datenbank von Samba übernommen werden.

Evtl. ist das bei TrueNAS nicht erforderlich gewesen, weil die Userverwaltung dort anders implementiert ist, d.h. das Samba-User-Mapping automatisch angelegt wird.

Viele Grüße, commodity

@commodity

Danke für den Hinweis, aber ich verstehe das Prinzip immer noch nicht.

Ich habe samba installiert (nicht samba-Server) und kann die gemountete über SMB-Share auf der NAS lesen. Um zu schreiben, muß der Linux Server bzw. der angemeldete Benutzer über Rechte verfügen.
Ich habe auf der NAS allen Usern vollen Zugriff gegeben. Dennoch meldet Ubuntu, daß es nicht schreiben kann. Nur der Root von Ubuntu kann auf der SMB chreiben.

Ich habe auch das von @7907292512 gepostete

sudo mount -t cifs -o "username=Bla,password=blub,uid=XXXX,gid=XXXX,forcegid,forceuid" //server/share /mnt/point

ausprobiert und erhalte einen Fehler

-bash: !,uid=1000,gid=1000,forcegid,forceuid: event not found

Ich habe jetzt die SMB-Share in fstab eingetragen mit Verweis auf eine Credentials-Datei für den user in /home/user/credentials
Auch hier funktioniert das Verbinden, aber eben ohne Schreibrechte.

ls -l gibt aus -rwxr-xr-x 1 root root 7933651456 Okt 13 23:05

Ich kann nur mit root-Rechten scheriben.

Ich habe es endlich geschafft, dank des Beitrags hier

Ich mußte in fastab eintragen 'noperm' und dann ging es.
//IP-SMB-share/directory /media/directory cifs credentials=/home/user/credentials,iocharset=utf8,noperm 0 0

Aber, ich habe es immer noch nicht verstanden.

Zitat von @vafk18:
sudo mount -t cifs -o "username=Bla,password=blub,uid=XXXX,gid=XXXX,forcegid,forceuid" //server/share /mnt/point

ausprobiert und erhalte einen Fehler

-bash: !,uid=1000,gid=1000,forcegid,forceuid: event not found

Liegt an Sonderzeichen deines Passwortes .
, single Quotes, oder escaping nutzen.

Aber, ich habe es immer noch nicht verstanden

Just RTFM on Fridays 🐟 and then happy ⛱️⛵
https://linux.die.net/man/8/mount.cifs

Zitat von @7907292512:

Liegt an Sonderzeichen deines Passwortes .

Ich habe in disem Password keine Sonderzeichen, d.h. es sind die exakten Buchstaben auf einer DE- wie auch US-Tastatur.

sorry, ich hatte den Task nicht verstanden. Du schreibst:
1.

Ich betreibe einen Ubuntu Server 20.04, dessen ausschließliche Aufgabe eine SQL-Datenbank unter MSSQL.

Ich möchte von einem Windows 11 mit MSSMS Backups der SQL-Datenbank auf eine SMB-Share erstellen. Die SMB ist auf einer TrueNAS Core. (FreeBSD).

Auf dem Ubuntu habe ich die SMB-Share \\192.168.2.11\Backups\Backup auf /mnt/smb_share gemountet.

Beim Versuch auf die SMB zu schreiben bekomme ich eine Fehlermeldung, daß ich keine Schreibrechte habe. Die Rechte sind 775.

Verstehe ich das richtig, dass das Backup aus Windows über SMSS angestoßen wird, dieses aber durch die SQL-DB auf dem Ubuntu ausgeführt und auf die Freigabe im NAS geschrieben werden soll? Wäre in diesem Falle nicht der SQL-User der schreibende User? Hat der Erlaubnis, auf das NAS zu schreiben?

Viele Grüße, commodity

@commodity

Genauso ist es. Mittlerweile habe ich es zum Laufen bekommen, aber nur indem ich in fastab den Zusatzeintrag 'noperm' vorgenommen habe.

//IP-SMB-share/directory /media/directory cifs credentials=/home/user/credentials,iocharset=utf8,noperm 0 0

Ich habe das problem gelöst, aber konnte nicht herausfinden, was 'noperm' bewirkt hat.

Ich habe das problem gelöst, aber konnte nicht herausfinden, was 'noperm' bewirkt hat.

Na, was es bewirkt, lässt sich ja auf der durch den Kollegen @7907292512 verlinkten Manpage nachlesen:

Client does not do permission checks. This can expose files on this mount to access by other users on the local client system. ...

Wenn meine Annahme richtig ist, dass der SQL-User das Backup initiiert, funktioniert das natürlich nicht, wenn dieser keine Rechte auf dem Share hat. Er kann bei 775 zwar lesen, aber nicht schreiben. Mit noperm wird das übergangen, da es dann allein auf die Rechte des mountenden Users ankommt.

Viele Grüße, commodity