Re: mounting nfs-share: Permission denied
Hallo Gerhard das war ja ein riesiges Mail. Vielen Dank, habe durch Deine ausfuehrliche Antwort viel gelernt. 1. bei einem mehr privaten Umfeld a) Du mußt die User der Clients und des Servers vereinheitlichen. Also die User, die Backups auf den Server stellen dürfen, müssen auch auf dem Server als User vorhanden sein, und zwar mit der gleichen User-ID. Dieser uids dürfen nicht überschneidend sein, also bei deinem Backup-User 1000/1000 darf es auf den Clients keinen geben, der auch die uid/gid 1000 hat. b) auf dem Server legst du eine Gruppe z.B. lbackup an. In diese Gruppe stellst du alle User die Backups anlegen dürfen plus deinen Backup-User, der das Backup ausführt. c) Du erstellst ein Verzeichniss z.B. /backups mit den Rechten drwxrwx--- 1000 lbackup Das Verzeichniss gehört also jetzt deinem Backup-User und jeder der Mitglied in der Gruppe lbackup ist, darf darin unter seiner uid schreiben. Dieses Verzeichniss exportierts du nun und zwar nur mit den Optionen (rw,root_squash). Du sparts dir also das explizite Ummappen der uid/gid auf 1000/1000. Werde mich wohl, da es um ein Heimnetzwerk geht, an diese Loesung halten. Meine erste Idee scheint mir nicht mehr so ideal ;-) Merci und Gruss Simon -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: mounting nfs-share: Permission denied
Vielen Dank an Gerhard, fuer die ausfuehrlichen Erklaerungen. So. Jetzt zu deinen exports. In deinem ersten Posting war dein export: /home/user/data/test client(ro,all_squash,anonuid=1000,anongid=1000) Du willst dieses Verzeichniss also -schreibgeschützt (ro), war ein Fehler im ersten Posting, sollte (rw) sein -anonym (uid/gid als nobody) (all_squash), -und dieser nobody soll auf dem Server der user 1000 / gid 1000 sein dem Rechner client zum mounten geben. Auf dem Server muß dann das Verzeichniss die Rechte drwxr-x---1 1000 1000 oder drwxrwx---1 root 1000 haben. Weil du ja explizit auf diese id mappen willst. Alle SubDirs und Files müssen latürnich auch für 1000/1000 lesbar sein. habe daher die Rechte auf drwxrwxrwx1 1000 1000 gesetzt So hat es schlussendlich auch geklappt. Noch eine kleine Frage: Was bedeutet eigentlich die 1 (drwxrwxrwx11000 1000)? Manchmal ist es ja auch eine 2. Warum ich die userid zugewiesen habe: Auf dem Server existiert ein User (uid 1000/gid 1000) der fuer die Backups zustaendig ist. Der User auf dem Client soll nun seine zu sichernden Dateien auf den gemounteten Share schieben, wo sie dann vom Backupuser zuerst (z.B. auf CD) gesichert und danach geloescht werden. Um Probleme mit den Userrechten zu vermeiden, soll eben jeder User unter der id des Backupusers schreiben. Ist das vernuenftig, oder sollte man das anders loesen? Gruss Simon -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: mounting nfs-share: Permission denied
High, high ... * [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am [03.07.03 10:36]: Vielen Dank an Gerhard, fuer die ausfuehrlichen Erklaerungen. So. Jetzt zu deinen exports. In deinem ersten Posting war dein export: /home/user/data/test client(ro,all_squash,anonuid=1000,anongid=1000) Du willst dieses Verzeichniss also -schreibgeschützt (ro), war ein Fehler im ersten Posting, sollte (rw) sein -anonym (uid/gid als nobody) (all_squash), -und dieser nobody soll auf dem Server der user 1000 / gid 1000 sein dem Rechner client zum mounten geben. Auf dem Server muß dann das Verzeichniss die Rechte drwxr-x---1 1000 1000 oder drwxrwx---1 root 1000 haben. Weil du ja explizit auf diese id mappen willst. Alle SubDirs und Files müssen latürnich auch für 1000/1000 lesbar sein. habe daher die Rechte auf drwxrwxrwx1 1000 1000 gesetzt So hat es schlussendlich auch geklappt. Noch eine kleine Frage: Was bedeutet eigentlich die 1 (drwxrwxrwx11000 1000)? Manchmal ist es ja auch eine 2. Kann ich dir nicht genau sagen, muß aber etwas mit der Anzahl der I-Nodes, die hinter der Datei bzw. den Verzeichnissen liegen, zu tun haben. Warum ich die userid zugewiesen habe: Auf dem Server existiert ein User (uid 1000/gid 1000) der fuer die Backups zustaendig ist. Der User auf dem Client soll nun seine zu sichernden Dateien auf den gemounteten Share schieben, wo sie dann vom Backupuser zuerst (z.B. auf CD) gesichert und danach geloescht werden. Um Probleme mit den Userrechten zu vermeiden, soll eben jeder User unter der id des Backupusers schreiben. Ist das vernuenftig, oder sollte man das anders loesen? Du quälst dich damit mit der klassischen Benutzerverwaltungs-Problematik herum. Dein Vorgehen hängt von verschiedenen Umständen ab, der wichtigste ist IMHO inwieweit dein Umfeld mehr privater oder geschäftlicher Natur ist. Letztlich ist die Frage: inwieweit kannst du deinen Benutzern gegen beabsichtlicher oder unbeabsichtlicher Manipulationen trauen. Und wie groß ist die Anzahl der Benutzer? Weil die Fehlerrate bekanntlich proportional zu Benutzerrate steigt. Und: wie sensibel sind die Daten, die da gesichert werden sollen? Nur mal kurz ein paar Beispiele / Hinweise / Gedankengänge: a) Um nach deiner Methode den Usern auf den Clients überhaupt die Möglichkeit zu geben, über nfs in den mount zu schreiben, mußtest du auf dem Server den Share rwxrwxrwx machen. Jetzt kann *auf* dem Server (lokal oder per telnet/ssh/nfs) aber *jeder* beliebige Daten in diesem Verzeichnis löschen oder neue erstellen. Ganz zu schweigen vom Lesen. b) Gemeinsame Rechte (ob uid oder gid) in einem Verzeichniss bergen immer Risiken. So kann User x die Backups von User y beliebig lesen oder löschen. Als Admin sollte man solche Konstellationen wenn es geht vermeiden und den Users (und sich selbst!) die Risiken vor Augen führen. c) Wenn du wie in a) angemerkt das Backupverzeichnis sowieso für *jeden* schreib/lesbar machen *mußt*, dann könntest du dir auch den Umweg über das User-Mapping sparen, da der User 1000/1000 auf dem Server ja auch alles darf (weil jeder). Ein rm -Rf /home/user/data/test/* wird dir das belegen. Wer was darf ergibt sich immer aus den Berechtigungen des gerade aktuellen Verzeichnisses. Wenn du z.B. als Normal-User in einem Verzeichnis schreibberechtigung hast, kann dort auch Dateien oder Verzeichnisse löschen (rm rmdir) die z.B. root gehören. Noch ein Beispiel, wo sich für dein Backup Probleme ergeben können: Die User können nur Einzel-Dateien in dein Backup-Verzeichniss stellen. User paul vom client kopiert Datei test.txt über nfs ins Backupdir. Diese gehört jetzt (wegen anonuid/anongid) dem user 1000/1000. User paul kann diese Datei jetzt nicht mehr verändern (da die Rechte auf dem Server ja jetzt bei Standard umask 0022 rw-r--r-- sind). Er kann sie aber noch löschen (da er ja in dem Verzeichniss ja Schreib-Berechtigung hat). Genauso kann sie aber auch User peter löschen. Wenn deine User neben Einzel-Dateien auch Verzeichnisse ins Backup-Dir stellen wollen, wird es richtig haarig. User paul möchte ein Verzeichniss paultexte *mit* enthaltenen Dateien ins Backup stellen. Das klappt nicht. Warum? paul kopiert das Verzeichniss paultexte. Das Verzeichniss paultexte wird auf dem Server auch noch angelegt, wechselt aber sofort den Besitzer (eben zu 1000/1000). Und dann kann der Kopiervorgang für die Dateien aus dem Verzeichniss paultexte nicht mehr fortgesetzt werden, weil das Verzeichniss auf dem Server ja nicht mehr paul gehört und er per default auch kein Schreibrecht mehr hat. Ich würde dir raten: 1. bei einem mehr privaten Umfeld a) Du mußt die User der Clients und des Servers vereinheitlichen. Also die User, die Backups auf den Server stellen dürfen, müssen auch auf dem Server als User vorhanden sein, und zwar mit der gleichen User-ID. Dieser uids dürfen nicht überschneidend sein, also bei deinem Backup-User 1000/1000 darf es
Re: mounting nfs-share: Permission denied
Vielen Dank an Gerhard und Achim Aber lassen sich nicht mounten: % mount 192.168.0.150:/test blub/ mount: 192.168.0.150:/test failed, reason given by server: Permission denied Mit -t nfs dasselbe Resultat. Du versuchst vom Server ein Verzeichnis /test (also Root(/) test) zu mounten. Das gibt es aber nicht. Richtig wäre: mount -t nfs 192.168.0.150:/home/user/data/test wohin_du_mounten_willst Also immer die Mountquelle so wie sie auch in den exports am Server festgelegt ist. Autsch, habe ich die Doku doch nicht richtig gelesen ... mounten ging so, allerdings bekam ich, als ich das Verzeichnis oeffnen wollte, wieder ein :Permission denied. Mittlerweilen geht aber gar nichts mehr. Ich wollte von einem zweiten Client auf den Server zugreiffen und habe die Berechtigungen und /etc/exports entsprechend geaendert. Nach einem exportfs -ra ist jedoch einfach nichts passiert. Die neuen Daten wurden nicht in /var/lib/nfs/xtab uebernommen. Auch nach einem Loeschen und einem Neustart tauchten die alten Einstellungen wieder auf. Schliesslich habe ich noch einen Eintrag in /var/lib/nfs/rmtab gefunden. Darauf habe ich die Files unter /var/lib/nfs/ geloescht (rmtab, etab, xtab, state) und neu erstellt (touch, chmod 644). Leider habe ich vergessen, vor dieser Aktion den NFS-Server zu stoppen. Jedenfall kriege ich jetzt bei einem Mount-Versuch auf den zweiten Client den folgenden Fehler: mount: RPC - Fehler des Portmappers - RPC : kann nicht empfangen Der zweite Client ist in /etc/hosts.allow eingetragen. Die Files /var/lib/nfs/xtab und /proc/fs/nfs/exports bleiben nach einem exportfs -ra weiter leer. Der Befehl exportfs gibt die shares korrekt an. Was habe ich mit dieser Aktion gekillt? Wie wuerde man in einem solchen Fall korrekt vorgehen? Merci und Gruss Simon -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: mounting nfs-share: Permission denied
High, high ... * [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am [30.06.03 01:10]: Also immer die Mountquelle so wie sie auch in den exports am Server festgelegt ist. Autsch, habe ich die Doku doch nicht richtig gelesen ... mounten ging so, allerdings bekam ich, als ich das Verzeichnis oeffnen wollte, wieder ein :Permission denied. Mittlerweilen geht aber gar nichts mehr. Dann solltest du deinem Rechner Beine machen ;-) Spaß beiseite. Grundsätzlich: der nfs-server erlaubt es bestimmten *Rechnern* Verzeichnisse des Servers zu mounten. Diese Verzeichnisse und die *Rechner* bzw Netzwerke werden am Server durch die /etc/exports festgelegt, plus Optionen die dann das Arbeiten mit diesen Verzeichnissen bestimmen. Nach dem Mounten greift dann die Benutzerverwaltung. D.h. der User vom Client muß *auf* dem Server die Rechte haben, um bestimmte Datei-Aktionen ausführen zu können. Bei Unixen sind Namen Schall und Rauch, letztendlich entscheidend sind die User-Id(uid) und die Group-Id(gid) auf dem jeweiligen System. Das setzt für die Berechtigungen also (ganz wichtig) voraus, das die uid und die gid für den jeweiligen Benutzer sowohl auf dem Server wie auch den Clients die gleichen sind. Gesichert ist das in der Regel nur bei root (uid 0, gid 0). Und root genießt bei nfs eine Sonderbehandlung. Per default verliert der root vom Client in den vom Server gemounteten Verzeichnissen seine root-Rechte, darf also nicht alles sehen/schreiben. Ich wollte von einem zweiten Client auf den Server zugreiffen und habe die Berechtigungen und /etc/exports entsprechend geaendert. Nach einem exportfs -ra ist jedoch einfach nichts passiert. Die neuen Daten wurden nicht in /var/lib/nfs/xtab uebernommen. exportfs -rav gibt mehr Informationen. Auch nach einem Loeschen und einem Neustart tauchten die alten Einstellungen wieder auf. Schliesslich habe ich noch einen Eintrag in /var/lib/nfs/rmtab gefunden. Darauf habe ich die Files unter /var/lib/nfs/ geloescht (rmtab, etab, xtab, state) und neu erstellt (touch, chmod 644). 644 für alle ist falsch. Diese Dateien/Dirs sollten so aussehen: [EMAIL PROTECTED]:/var/lib/nfs$ ls -l insgesamt 20 -rw-r--r--1 root root 149 2003-06-30 19:41 etab -rw-r--r--1 root root 87 2003-05-17 13:42 rmtab drwxr-xr-x2 root root 4096 2003-03-23 23:55 sm drwxr-xr-x2 root root 4096 2003-03-23 23:55 sm.bak -rw---1 root root4 2003-06-30 19:41 state -rw-r--r--1 root root0 2003-06-30 19:41 xtab Leider habe ich vergessen, vor dieser Aktion den NFS-Server zu stoppen. Jedenfall kriege ich jetzt bei einem Mount-Versuch auf den zweiten Client den folgenden Fehler: mount: RPC - Fehler des Portmappers - RPC : kann nicht empfangen Der zweite Client ist in /etc/hosts.allow eingetragen. Die Files /var/lib/nfs/xtab und /proc/fs/nfs/exports bleiben nach einem exportfs -ra weiter leer. Der Befehl exportfs gibt die shares korrekt an. Was habe ich mit dieser Aktion gekillt? Wie wuerde man in einem solchen Fall korrekt vorgehen? Also mach mal folgendes (ich gehe davon aus das du am Server schalten und walten kannst wie du willst ohne jemand zu stören): 1. /etc/init.d/nfs-kernel-server stop 2. /etc/init.d/portmap stop 3. Datein u. Dirs aus /var/lib/nfs wieder wie oben in Form bringen So. Jetzt zu deinen exports. In deinem ersten Posting war dein export: /home/user/data/test client(ro,all_squash,anonuid=1000,anongid=1000) Du willst dieses Verzeichniss also -schreibgeschützt (ro), -anonym (uid/gid als nobody) (all_squash), -und dieser nobody soll auf dem Server der user 1000 / gid 1000 sein dem Rechner client zum mounten geben. Auf dem Server muß dann das Verzeichniss die Rechte drwxr-x---1 1000 1000 oder drwxrwx---1 root 1000 haben. Weil du ja explizit auf diese id mappen willst. Alle SubDirs und Files müssen latürnich auch für 1000/1000 lesbar sein. /etc/hosts.allow ist IMHO für nfs nicht relevant. auch mit exportfs würde ich mich erstmal nicht rumschlagen. Nach Änderungenen an den exports ein beherztes stop/start des nfs-kernel-servers langt. Jetzt 4. /etc/init.d/portmap start 5. /etc/init.d/nfs-kernel-server start Jetzt auf dem Client mounten. Jeder User und root vom Client sollte jetzt lesend auf den mount zugreifen können. Schreiben verbietest du ja. Falls das nicht funktionieren sollte: bitte mal folgende Infos zeigen: ls -la /home/user/data/test exportfs -v Auch kannst du ja testweise mal den share offenmachen. in die /etc/exports: /home/user/data/test192.168.0.0/255.255.255.0(rw,no_root_squash) Jeder client aus dem Subnet sollte mounten können. Root sollte nach dem mounten root alles dürfen. Ein normaler Userr, wenn uid/gid auf client und server übereinstimmen, kann das tun, was er auch auf dem Server tun könnte. Merci und Gruss Simon Gruß Gerhard pgp0.pgp Description: PGP signature
Re: mounting nfs-share: Permission denied
High, high ... * [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am [27.06.03 02:32]: Irgendwie bringen ich meinen NFS-Server nicht dazu seine Exports freizugeben. ... Die Exports werden scheinbar auch wirklich angeboten: % showmount -e 192.168.0.150 Exports list on 192.168.0.150: /home/user/data/test client Aber lassen sich nicht mounten: % mount 192.168.0.150:/test blub/ mount: 192.168.0.150:/test failed, reason given by server: Permission denied Mit -t nfs dasselbe Resultat. Du versuchst vom Server ein Verzeichnis /test (also Root(/) test) zu mounten. Das gibt es aber nicht. Richtig wäre: mount -t nfs 192.168.0.150:/home/user/data/test wohin_du_mounten_willst Also immer die Mountquelle so wie sie auch in den exports am Server festgelegt ist. Merci und Gruss Simon Gruß Gerhard pgp0.pgp Description: PGP signature
Re: mounting nfs-share: Permission denied
On Fri, 27 Jun 2003 [EMAIL PROTECTED] wrote: Hallo zusammen Irgendwie bringen ich meinen NFS-Server nicht dazu seine Exports freizugeben. System: woddy mit 2.4.21 Ich habe folgende Einstellungen vorgenommen: /etc/exports: /home/user/data/test client(ro,all_squash,anonuid=1000,anongid=1000) # uid und gid von user auf dem Server /etc/hosts: 192.168.0.100 client /etc/hosts.allow: ALL: client Nach einem exportfs -ra steht in /proc/fs/nfs/exports folgendes: # Version 1.1 # Path Client(Flags) # IPs /home/user/data/test client(ro,root_squash,all_squash,async,wdelay) # 192.168.0.100 Der Server und der Client lassen sich gegenseitig pingen. Ein rcpinfo zeigt folgendes: % rpcinfo -p 192.168.0.150 program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000241 udp 32768 status 1000241 tcp 32768 status 132 udp 2049 nfs 1000211 udp 32770 nlockmgr 1000213 udp 32770 nlockmgr 151 udp 32771 mountd 151 tcp 32769 mountd 152 udp 32771 mountd 152 tcp 32769 mountd Die Exports werden scheinbar auch wirklich angeboten: % showmount -e 192.168.0.150 Exports list on 192.168.0.150: /home/user/data/test client Aber lassen sich nicht mounten: % mount 192.168.0.150:/test blub/ mount: 192.168.0.150:/test failed, reason given by server: Permission denied versuch mal mount 192.168.0.155:/home/user/data/test blub sieht doch besser aus, oder? Gruss Achim -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
