On Wed, Jun 04, 2008 at 04:10:58PM +0200, Martin Schuster (IFKL IT OS DSM CD) wrote: > I am in the process of setting up an "NFS-proxy", a machine which > mounts directories from an NetApp-filer using NFS3, and should re-export > them using NFS4 (with Kerberos). > > But apparently nfsd doesn't support re-exporting NFS-mounted dirs: > # mount | grep home > netapp.example.com:/vol/home/schumar on /srv/nfs4/home/schumar type nfs > # cat /etc/exports > /srv/nfs4/home/schumar gss/krb5(rw,sync,fsid=0,secure,no_subtree_check) > # exportfs -r > exportfs: Warning: /srv/nfs4/home/schumar does not support NFS export. > > I traced this back to linux-2.6.25.1/fs/nfsd/export.c, where it says, starting > in line 386: > if (!inode->i_sb->s_export_op || > !inode->i_sb->s_export_op->fh_to_dentry) { > dprintk("exp_export: export of invalid fs type.\n"); > return -EINVAL; > } > > (and a quick look in fs/nfs/super.c confirmed that the nfs-client never > sets an export_op) > > Is there a technical reason for this (i.e. is it simply theoretically > impossible to re-export an NFS-mount), or is my use-case so strange that > nobody has ever needed this until now, and thus it just wasn't coded? It's certainly not trivial to implement re-export. It's probably also possible, at least in theory, but would be difficult (and probably wouldn't work terribly well). So, like Peter Staubach says, I'd try to talk the server administrator into turning on krb5 on the filer. --b. > Or am I just stupid/blind? (wouldn't be the first time :) > > Thanks in advance, > -- > Infineon Technologies IT-Services GmbH Martin.Schuster1@xxxxxxxxxxxx > Lakeside B05, 9020 Klagenfurt, Austria Martin Schuster > FB: LG Klagenfurt, FN 246787y +43 5 1777 3517 > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html