On Samstag, 21. November 2009 Christoph Hellwig wrote:
> So your NFS exports are not the roots of their respsective
That's the way it works with NFSv4. You create an NFS root dir with a
special entry in /etc/exports:
and if you want other parts exported, create a dir there and mount it:
mount --bind /mydata /nfsserver/data
This just takes the inodes from there and creates something like a view
into this dir. From the client, you
mount -t nfs4 server:/data /serverdata
and you get the /nfsserver/data mounted there.
> This means NFSD uses non-standard filesystem IDs in the
> filehandles which have to encode the inode number of the export
> root. Your best option is to simplify switch to exporting a whole
That's how it worked until NFSv3. I tried that also, didn't work either.
The whole thing worked before I reinstalled it (this server now runs
virtualized within XENserver), and maybe that made some subdirs have
inodes > 32bit.
> alternatively you can try making sure NFSD uses the
> 16byte wide UUID style export.
How'd I do that?
> Note thast either way will only work
> with a 64bit kernel as the fs has no say in encoding the filesystem
> part of the handle and ino_t is always 32bit on 32bit platforms.
> This will also affect any other filesystem with 64bit inode numbers.
Not my problem, everything 64bit here. I use the kernel-nfsd, and that's
why I was wondering to have this problem.
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
Description: This is a digitally signed message part.