[NFS4] userid mappen niet

[Sir Isaac]

Ik heb zojuist NFS4 opgezet omdat ssh mij te langzaam was. Ik kan nu inderdaad 3x zo snel files over pompen. User mapping gaat alleen niet goed:

ls -l
...
drwxr-xr-x  2 4294967294 4294967294         48 2009-04-19 16:06 net
...

De configuratie van mijn Debian server:

/etc/exports:
/export       192.168.0.0/24(rw,fsid=0,root_squash,subtree_check)
/export/user  192.168.0.0/24(rw,root_squash,subtree_check,nohide)

/etc/fstab: 
/home/user	/export/user	none	bind	0	0

Ik zie dat idmapd niet draait, hoewel ik ik /etc/default/nfs-common NEED_IDMAPD=yes heb staan. Maar als ik nfs-common herstart krijg ik:

Starting NFS common utilities: idmapdrpc.idmapd: libnfsidmap: using domain: localdomain

rpc.idmapd: libnfsidmap: using translation method: nsswitch

 failed!

NFS4 is in vergelijking met NFS3 wel simpeler, maar ik vraag me of FTP niet handiger is voor backup doeleinden. Ik hoef de netwerk shares net perse te mounten. Een ad-hoc verbinding voldoet ook.

[Kees]

start rpc.idmapd

Wat is de inhoud van de idmapd config? En zijn de users op de servers gelijk? Als de server user 'piet/1000' niet kent, dan zul je op de client zien dat files die een userid van 1000 hebben als 'nobody' geexporteerd worden. En je kan het dan ook niet veranderen, tenzij je user piet/1000 op de server aanmaakt.

Als je de shares niet perse hoeft te mounten, gebruik dan rsync voor backup doeleinden, of eventueel sftp, ftp zelf is een oud ranzig protocol dat dood moet.

[Rainmaker]

En, zoals je in je config hebt staan, staat ook root_squash nog eens aan.

Als je dus als root (client) files wegschrijft, zul je ook dit soort UID/GID's op je files krijgen.

offtopic:
Als je trouwens meerdere clients naar die NFS share wil laten backuppen, gebruik geen mounts. Als 1 client dan ineens besluit alle files te verwijderen, ben je je backups van alle andere clients ook kwijt.

[ Voor 39% gewijzigd door Rainmaker op 14-11-2009 14:07 ]

[Sir Isaac]

Mijn idmap.cfg ziet er zowel op de server als op de client zo uit:

code:

[General]

Verbosity = 1
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Nobody heeft userid 65534, en ik benader de share niet als root, dus de root_squash veroorzaakt dit niet. De usernames zijn gelijk, de userid's zijn volgens mij ook, maar de client kan ik nu niet controleren. Maar waar heb je en idmapd voor nodig als de id's gelijk zijn? Dan hoeft er niets gemapt te worden.

Verder off-topic @ Kees. Ik heb proftpd inmiddels ook draaien, en dat koste maar weinig moeite. Wat is er volgens zo ranzig aan ftp volgens jou? Active mode ftp is voor de server goed te firewallen.
SMB heeft veel overhead, NFS is niet handig voor adhoc verbindingen. Webdav zou een alternatief kunnen zijn. Heeft dav minder poorten nodig?

[Kees]

Het lijkt er bijna op alsof je client geen user nobody heeft, of dat daar iets verkeerd aan gaat. De bestanden krijgen namelijk de userid van user nobody mee. En ja, id's hoeven niet gelijk te zijn, maar dat is wel zo makkelijk om wel gelijk te hebben

En waarom ik ftp een ranzig protocol vind; het is totaal verschillend van de 'gangbare' protocollen met zijn out of band control en aparte data channel, vandaar dat ik sftp (ssh-ftp) een veel mooiere oplossing vind, waarbij je ook nog eens een poort minder open hebt staan.

[Sir Isaac]

M'n client draait Ubuntu 9.10, net als de laptop waar ik nu achter zit. Hier heb ik wel degelijk een nobody user met als uid 65534, dat zal voor mijn machine thuis ook wel gelden.
sftp gebuik ik ook, maar dat is gewoon een factor 3-3.5 langzamer dan NFS of FTP. Voor verbinding van buiten maakt het niet uit, die zijn toch niet zo snel en dan is veiligheid erg belangrijk, maar intern wil ik iets snellers.