nfs als user via fstab mounten

[Max Bloch]

Hallo Liste,

ich bekomme es leider nicht hin ein nfs nach meinen Wünschen im fstab
automatisch zu mounten. Ich wünsche mir das nfs als user 'max' und group
'users' mit ug+rw Rechten zu mounten. Mein fstab hat dazu den folgenden
Eintrag:

192.168.178.10:/share/Qmultimedia /mnt/schmas/Qmultimedia nfs
defaults,user,nfsvers=3 0 0

Der Mountpoint /share/Qmultimedia ist folgendermaßen angelegt:
drwxrwxr-x  2 max  users 4096 2008-03-24 22:32 Qmultimedia

Nach dem mounten sieht es so aus:
drwxrwxrwx  8 root root 4096 25. Sep 14:53 Qmultimedia

UID und GUID für max:users sind auf beiden Systemen dieselben.

Das NFS wird zwar gemounted, aber als root. Schreiben auf das gemountete
NFS erfolgt als 'guest' user.

Kann mir jemand eventuell weiterhelfen?

Vielen lieben Dank
Max

[Dirk Heinrichs-2]

Am Dienstag 29 September 2009 10:14:13 schrieb Max Bloch:

> ich bekomme es leider nicht hin ein nfs nach meinen Wünschen im fstab
> automatisch zu mounten. Ich wünsche mir das nfs als user 'max' und group
> 'users' mit ug+rw Rechten zu mounten. Mein fstab hat dazu den folgenden
> Eintrag:

NFS ist _kein_ Windows Filesystem. Du siehst auf dem Client genau dieselben
Rechte die das exportierte Verzeichnis auf dem Server hat.

Bye...

        Dirk

[Roland Huehn]

Dirk Heinrichs schrieb:

> Am Dienstag 29 September 2009 10:14:13 schrieb Max Bloch:
>
>> ich bekomme es leider nicht hin ein nfs nach meinen Wünschen im fstab
>> automatisch zu mounten. Ich wünsche mir das nfs als user 'max' und group
>> 'users' mit ug+rw Rechten zu mounten. Mein fstab hat dazu den folgenden
>> Eintrag:
>
> NFS ist _kein_ Windows Filesystem. Du siehst auf dem Client genau dieselben
> Rechte die das exportierte Verzeichnis auf dem Server hat.
>

Um es noch genauer zu sagen uid und gid (user, group) können od. sind

aller Wahrscheinlichkeit auf beiden systemen unterschiedlich.

Du könntest einen Verzeichnisdienst wie LDAP einsetzen oder, du legst
den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
z.B:

10.11.65.2(rw,all_squash,anonuid=1000,anongid=1001,no_subtree_check,async)

Grüße, Roland
> Bye...
>
> Dirk
>

[Dirk Heinrichs-2]

Am Dienstag 29 September 2009 18:39:02 schrieb Roland Huehn:

> Um es noch genauer zu sagen uid und gid (user, group) können od. sind
> aller Wahrscheinlichkeit auf beiden systemen unterschiedlich.

Komisch, mir war als hätte Max geschrieben, daß sie identisch sind.

> Du könntest einen Verzeichnisdienst wie LDAP einsetzen oder, du legst
> den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
> auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
> z.B:

Warum? Er braucht nur die Rechte auf dem Server schon wie benötigt setzen.

Bye...

        Dirk

[Roland Huehn]

Dirk Heinrichs schrieb:
> Am Dienstag 29 September 2009 18:39:02 schrieb Roland Huehn:
>
>> Um es noch genauer zu sagen uid und gid (user, group) können od. sind
>> aller Wahrscheinlichkeit auf beiden systemen unterschiedlich.
>
> Komisch, mir war als hätte Max geschrieben, daß sie identisch sind.

Das besprichst du besser mit Max.

>
>> Du könntest einen Verzeichnisdienst wie LDAP einsetzen oder, du legst
>> den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
>> auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
>> z.B:
>
> Warum? Er braucht nur die Rechte auf dem Server schon wie benötigt setzen.
>

Weil eben die Benutzer Gruppenzugehörigkeit über die uid,gid
ausgetauscht wird kennt der Server diese nicht verweigert er den Zugriff
ist die uid,gid mit der der client zugreift schon für einen anderen
user, grupe vergeben wird diese auch auf dem Server verwendet was doch
wiederum voraussetzt daß, uid,gid auf beiden systemen Client und Server
die selben sein müssen um correcte Zugriffsrechte setzen zu können.

So und nun kann man eben in der exports angeben das alle Zugriffe auf
eben nur eine uid,gid gemapd werden und es völlig egal ist mit welcher
uid,gid ein client zugreift.

Aus diesem Grund existieren auch z.B auch die no_root_squash und
root_squash optionen um, zu verhindern daß, jeder user dateien mit root
uid=0,gid=0 welche ja auf jeden System die selben sind anlegen kann...

Aber korrigiere mich bitte wenn ich völlig daneben liege.

Gruß, Roland

> Bye...
>
> Dirk
>

[Roland Huehn]

Roland Huehn schrieb:

> Dirk Heinrichs schrieb:
>> Am Dienstag 29 September 2009 18:39:02 schrieb Roland Huehn:
>>
>>> Um es noch genauer zu sagen uid und gid (user, group) können od. sind
>>> aller Wahrscheinlichkeit auf beiden systemen unterschiedlich.
>> Komisch, mir war als hätte Max geschrieben, daß sie identisch sind.
>
> Das besprichst du besser mit Max.
>
>>> Du könntest einen Verzeichnisdienst wie LDAP einsetzen oder, du legst
>>> den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
>>> auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
>>> z.B:
>> Warum? Er braucht nur die Rechte auf dem Server schon wie benötigt setzen.
>>
>
> Weil eben die Benutzer Gruppenzugehörigkeit über die uid,gid
> ausgetauscht wird kennt der Server diese nicht verweigert er den Zugriff
> ist die uid,gid mit der der client zugreift schon für einen anderen
> user, grupe vergeben wird diese auch auf dem Server verwendet was doch
> wiederum voraussetzt daß, uid,gid auf beiden systemen Client und Server
> die selben sein müssen um correcte Zugriffsrechte setzen zu können.
>
> So und nun kann man eben in der exports angeben das alle Zugriffe auf
> eben nur eine uid,gid gemapd werden und es völlig egal ist mit welcher
> uid,gid ein client zugreift.
>
> Aus diesem Grund existieren auch z.B auch die no_root_squash und
> root_squash optionen um, zu verhindern daß, jeder user dateien mit root
> uid=0,gid=0 welche ja auf jeden System die selben sind anlegen kann...
>
> Aber korrigiere mich bitte wenn ich völlig daneben liege.

Ok,
so ganz unrecht hast du doch nicht in der manpage steht das uid,gid vom
Server unter vorausetzung der option map_daemon und einen laufenden
rpc.ugidd auf dem Clienten dynamisch umgewandelt weden können.

>
> Gruß, Roland
>
>> Bye...
>>
>> Dirk
>>
>
>

[Dirk Heinrichs-2]

Am Dienstag 29 September 2009 20:53:03 schrieb Roland Huehn:
> > Aber korrigiere mich bitte wenn ich völlig daneben liege.
>
> Ok,
> so ganz unrecht hast du doch nicht in der manpage steht das uid,gid vom
> Server unter vorausetzung der option map_daemon und einen laufenden
> rpc.ugidd auf dem Clienten dynamisch umgewandelt weden können.

Es braucht gar nix umgewandelt werden. Auf dem Server das exportierte
Verzeichnis mit chmod/chown auf die richtigen Rechte setzen und gut ist.

Bye...

        Dirk

[Max Bloch]

Dirk Heinrichs wrote:
> NFS ist _kein_ Windows Filesystem. Du siehst auf dem Client genau
dieselben
> Rechte die das exportierte Verzeichnis auf dem Server hat.

Ok, das ist mir schon klar. Ich habe mich wohl ungeschickt ausgedrückt.


Roland Huehn wrote:
> ... oder, du legst
> den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
> auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
> z.B:
> 10.11.65.2(rw,all_squash,anonuid=1000,anongid=1001,no_subtree_check,async)

Danke, das klingt doch nach einer Lösung. Allerdings würde ich es
bevorzugen keine Mappings zu verwenden. Mein /etc/exports sieht so aus:

"/share/HDA_DATA/Qmultimedia" *(rw,async,no_root_squash)

Max Bloch wrote:
> Schreiben auf das gemountete NFS erfolgt als 'guest' user.

Hier ein Beispiel:

client# cat /etc/fstab
192.168.178.10:/share/Qmultimedia /mnt/schmas/Qmultimedia nfs
          defaults,user,nfsvers=3 0 0

client# pwd
/mnt/schmas/Qmultimedia

client# ls -la
drwxrwxrwx 5 root  root       4096 15. Aug 08:09 .

client# mkdir test
client# ls -la
drwxrwxrwx  5 root   root    4096 15. Aug 08:09 .
drwxr-xr-x  2 nobody nobody  4096 29. Sep 20:08 test

client# whoami
max

Auf dem Server gibt es ebenso den user 'max' mit der selben UID wie auf
dem client.

Das sieht für mich aus als ob mein Zugriff gesquashed wurde?!? Ob
vielleicht das no_root_squash in meiner /etc/exports dafür
verantwortlich ist? In meinem Beispiel habe ich 'mkdir test' aber doch
als user 'max' ausgeführt und nicht als root. Habe ich da vielleicht was
falsch verstanden?

Ich frage mich gerade welcher user in meinem Beispiel nun auf das nfs
zugegriffen hat? War es 'max' der den Befehl 'mkdir test' ausgeführt
hat, oder war es 'root' der das nfs via fstab wahrscheinlich gemounted
hat? Vielleicht liegt hier der Lösungsansatz?

LG Max

[Dirk Heinrichs-2]

Am Dienstag 29 September 2009 21:41:46 schrieb Max Bloch:

> Dirk Heinrichs wrote:
> > NFS ist _kein_ Windows Filesystem. Du siehst auf dem Client genau
>
> dieselben
>
> > Rechte die das exportierte Verzeichnis auf dem Server hat.
>
> Ok, das ist mir schon klar. Ich habe mich wohl ungeschickt ausgedrückt.
>
> Roland Huehn wrote:
> > ... oder, du legst
> > den user auf dem Server ebenfalls an un mapst dann in der /etc/exports
> > auf dem Server mit anonuid,anongid auf die uid,gid des angelegten users.
> > z.B:
> > 10.11.65.2(rw,all_squash,anonuid=1000,anongid=1001,no_subtree_check,async
> >)
>
> Danke, das klingt doch nach einer Lösung. Allerdings würde ich es
> bevorzugen keine Mappings zu verwenden. Mein /etc/exports sieht so aus:
>
> "/share/HDA_DATA/Qmultimedia" *(rw,async,no_root_squash)
>
> Max Bloch wrote:
> > Schreiben auf das gemountete NFS erfolgt als 'guest' user.
>
> Hier ein Beispiel:
>
> client# cat /etc/fstab
> 192.168.178.10:/share/Qmultimedia /mnt/schmas/Qmultimedia nfs
>           defaults,user,nfsvers=3 0 0
>
> client# pwd
> /mnt/schmas/Qmultimedia
>
> client# ls -la
> drwxrwxrwx 5 root  root       4096 15. Aug 08:09 .
>
> client# mkdir test
> client# ls -la
> drwxrwxrwx  5 root   root    4096 15. Aug 08:09 .
> drwxr-xr-x  2 nobody nobody  4096 29. Sep 20:08 test
>
> client# whoami
> max
>
> Auf dem Server gibt es ebenso den user 'max' mit der selben UID wie auf
> dem client.
>
> Das sieht für mich aus als ob mein Zugriff gesquashed wurde?!? Ob
> vielleicht das no_root_squash in meiner /etc/exports dafür
> verantwortlich ist?

Nein.

> In meinem Beispiel habe ich 'mkdir test' aber doch
> als user 'max' ausgeführt und nicht als root. Habe ich da vielleicht was
> falsch verstanden?

Nein, das ist schon richtig.

> Ich frage mich gerade welcher user in meinem Beispiel nun auf das nfs
> zugegriffen hat? War es 'max' der den Befehl 'mkdir test' ausgeführt
> hat, oder war es 'root' der das nfs via fstab wahrscheinlich gemounted
> hat?

Es war max.

> Vielleicht liegt hier der Lösungsansatz?

Bist Du sicher, das die /etc/exports stimmt? Das obige Beispiel deutet auf
"all_squash" hin. Hattest Du die vielleicht mal drin, und nach Entfernung
vielleicht die Serverprozesse nicht neu gestartet?

Bye...

        Dirk

[Max Bloch]

Dirk Heinrichs wrote:

> Am Dienstag 29 September 2009 21:41:46 schrieb Max Bloch:
>>
>> Mein /etc/exports sieht so aus:
>>
>> "/share/HDA_DATA/Qmultimedia" *(rw,async,no_root_squash)
>>
>> Max Bloch wrote:
>>> Schreiben auf das gemountete NFS erfolgt als 'guest' user.
>> Hier ein Beispiel:
>>
>> client# cat /etc/fstab
>> 192.168.178.10:/share/Qmultimedia /mnt/schmas/Qmultimedia nfs
>>           defaults,user,nfsvers=3 0 0
>>
>> client# pwd
>> /mnt/schmas/Qmultimedia
>>
>> client# ls -la
>> drwxrwxrwx 5 root  root       4096 15. Aug 08:09 .
>>
>> client# mkdir test
>> client# ls -la
>> drwxrwxrwx  5 root   root    4096 15. Aug 08:09 .
>> drwxr-xr-x  2 nobody nobody  4096 29. Sep 20:08 test
>>
>> client# whoami
>> max
>>
>> Auf dem Server gibt es ebenso den user 'max' mit der selben UID wie auf
>> dem client.
>>
>> Das sieht für mich aus als ob mein Zugriff gesquashed wurde?!? Ob
>> vielleicht das no_root_squash in meiner /etc/exports dafür
>> verantwortlich ist?
>
> Nein.
>
>> In meinem Beispiel habe ich 'mkdir test' aber doch
>> als user 'max' ausgeführt und nicht als root. Habe ich da vielleicht was
>> falsch verstanden?
>
> Nein, das ist schon richtig.
>
>> Ich frage mich gerade welcher user in meinem Beispiel nun auf das nfs
>> zugegriffen hat? War es 'max' der den Befehl 'mkdir test' ausgeführt
>> hat, oder war es 'root' der das nfs via fstab wahrscheinlich gemounted
>> hat?
>
> Es war max.
>
>> Vielleicht liegt hier der Lösungsansatz?
>
> Bist Du sicher, das die /etc/exports stimmt? Das obige Beispiel deutet auf
> "all_squash" hin. Hattest Du die vielleicht mal drin, und nach Entfernung
> vielleicht die Serverprozesse nicht neu gestartet?

Das glaube ich nicht. Mal testen:

server# /etc/init.d/nfs restart
Shutting down NFS daemon:  rpc.nfsd.
Shutting down NFS mountd:  rpc.mountd.
Shutting down NFS quotas:  rpc.rquotad.
Stopping portmap.
Starting NFS services: Starting portmapper:.
re-export.
Starting NFS quotas:  rpc.rquotad.
Starting NFS mountd daemon: Shutting down NFS mountd:
Starting NFS mountd. Mountd port number assigned automatically.
Starting NFS daemon:  rpc.nfsd
Starting NFS lockd status:.

server# cat /etc/exports
"/share/HDA_DATA/Qmultimedia" *(rw,async,no_root_squash)

Auf der Client Seite sehe ich immer noch das gesquaschte Verhalten :(
Nun weiss ich selber nicht mehr weiter. Ich ziehe in Erwägung den Server
zu rebooten in der Hoffnung das Problem löst sich von selber, auch wenn
mir das unter Linux noch nie geholfen hat (Ach wie schön waren die
Windows Zeiten wenn man mit einem einfachem reboot ein Problem lösen
konnte <kleiner Scherz>)

Gestern dachte ich noch das Problem könnte client seitig sein,
vielleicht am falschen mounten, da ich öfter am client herum
konfiguriere. Nun sieht es aber für mich so aus als ob es am Server
liegt, auch wenn ich dort keinen Fehler sehe. Hier noch einige Infos die
wahrscheinlich nicht witerhelfen. Auf meinem client (desktop) läuft
Gentoo, der Server ist ein Qnap TS-109 Pro NAS mit vorinstalliertem
Linux. /etc/export wird beim /etc/init.d/nfs restart neu geschrieben,
anhand einer eigenen Konfiguration die über ein Web-interface gesteuert
angelegt wird. Bis vor einigen Wochen hat das gemountete nfs ohne
squashing korrekt fuktioniert. Am server habe ich keine Einstellungen
wissentlich geändert. Nun bin ich ratlos.

...Max

[Dirk Heinrichs-2]

Am Mittwoch 30 September 2009 10:25:50 schrieb Max Bloch:

> Gestern dachte ich noch das Problem könnte client seitig sein,
> vielleicht am falschen mounten, da ich öfter am client herum
> konfiguriere. Nun sieht es aber für mich so aus als ob es am Server
> liegt, auch wenn ich dort keinen Fehler sehe. Hier noch einige Infos die
> wahrscheinlich nicht witerhelfen. Auf meinem client (desktop) läuft
> Gentoo, der Server ist ein Qnap TS-109 Pro NAS mit vorinstalliertem
> Linux. /etc/export wird beim /etc/init.d/nfs restart neu geschrieben,
> anhand einer eigenen Konfiguration die über ein Web-interface gesteuert
> angelegt wird. Bis vor einigen Wochen hat das gemountete nfs ohne
> squashing korrekt fuktioniert. Am server habe ich keine Einstellungen
> wissentlich geändert. Nun bin ich ratlos.

Hmm, wie sieht denn auf dem Server /var/lib/nfs/etab aus? Da sollten die
tatsächlichen Export-Optionen drinstehen.

Bye...

        Dirk

[Max Bloch]

Dirk Heinrichs wrote:

> Am Mittwoch 30 September 2009 10:25:50 schrieb Max Bloch:
>
>> Gestern dachte ich noch das Problem könnte client seitig sein,
>> vielleicht am falschen mounten, da ich öfter am client herum
>> konfiguriere. Nun sieht es aber für mich so aus als ob es am Server
>> liegt, auch wenn ich dort keinen Fehler sehe. Hier noch einige Infos die
>> wahrscheinlich nicht witerhelfen. Auf meinem client (desktop) läuft
>> Gentoo, der Server ist ein Qnap TS-109 Pro NAS mit vorinstalliertem
>> Linux. /etc/export wird beim /etc/init.d/nfs restart neu geschrieben,
>> anhand einer eigenen Konfiguration die über ein Web-interface gesteuert
>> angelegt wird. Bis vor einigen Wochen hat das gemountete nfs ohne
>> squashing korrekt fuktioniert. Am server habe ich keine Einstellungen
>> wissentlich geändert. Nun bin ich ratlos.
>
> Hmm, wie sieht denn auf dem Server /var/lib/nfs/etab aus? Da sollten die
> tatsächlichen Export-Optionen drinstehen.

server#cat /var/lib/nfs/etab
/share/HDA_DATA/Qmultimedia
*(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,subtree_check,secure_locks,acl,mapping=identity,anonuid=65534,anongid=65534)

Hier sehe ich ebenso keinen Grund gesquasched zu werden. Diese Datei war
mir bis eben unbekannt. Hiermit habe ich mich noch nicht weiter befasst.
Für heute reicht es mir. Morgen gucke ich weiter.

...Max