spamisevi1@yahoo.com (Mike Eisler) wrote in message news:<36f0f19f.0407070450.511d1f0c@posting.google.com>...
> "Nico Kadel-Garcia" wrote in message news:...
> > Mike Eisler wrote:
> > > paul.richards@gmail.com (Paul Richards) wrote in message
> > > news:...
> > >> Hi,
> > >> I have an nfs export set up as follows in my /etc/exports:
> > >>
> > >> /a spongebob(rw)
> > >>
> > >> Which (surprisingly enough) the machine spongebob can mount OK..
> > >>
> > >> The problem comes where I have some samba mounts on the server
> > >> located at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine
> > >> spongebob can't access anything from inside of the samba mounts..
> > >> It can see that the directories 1, 2, and 3 exist, and can even cd
> > >> into them. It just doesn't see any of the files inside and can't
> > >> open them.
> > >
> > > NFS servers will typically not let clients cross a server's mount
> > > point.
> >
> > This is completely correct. There are a ton of reasons for this, but
> > allowing machine C to inherit permissions from machine B to access things on
> > machine A just breaks a lot of security and file locking paradigms.
> > Transitive directory mounting is just a big, big, big problem.
>
> Sure but unless there's an "is_remote" interface that the NFS server
> can use to query the file system being accessed, this is not the
> reason
> why NFS servers don't allow mount point crossing. The primary reason
> they
> don't is that NFS clients are suually implemented on POSIX compatible
> systems, which expect a unique inode#/fsid# for each file. The NFS
> client generates its own fsid for each NFS mount point. If the server
> allowed mount point crossing, then unique inode#s could not be
> generated,
> which often produces operational problems on the client.
>
> NFS servers typically can't export NFS mounts because of the way the
> file handle is constructed; it turns out that attempting to do so
> at minimum doubles the size of the NFS file handle, which is not
> infinite in length.
>
> > > Try exporting the samba mounts. This assumes the samba file system
> > > will allow NFS exporting.
> >
> > Try the reverse. You can SMB export almost anything, including other SMB
> ^^^^^^^^^^^^^^^^^^
> That only works if the NFS client also has an SMB client, which was
> not
> specified in the original post. If this were so, then there's be no
> point in original question.


I am not totally sure that I understand why changing my /a mount to be
a samba share would fix things.. Would I really be able to navigate
into /a/mounts/1, etc..? How does samba get around the problem that
NFS has?


In this case the client machine (Solaris 9) does have a samba client
available. The only problem is that I'm not sure how well samba
handles the unix file permissions. Does anyone know if my system will
be happy having home directories mounted over samba?



>
> > mounts and including NFS mounts. Alternatively, set up the SMB mount to be
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> So to quote you: "allowing machine C to inherit permissions from
> machine B to access things on machine A just breaks a lot of security
> and file locking paradigms. Transitive directory mounting is just a
> big, big, big problem."
>
> Why is it, if NFS does it, it's a problem, but if an SMB server does
> it, it
> is not?
>
> > mounted somewhere else on machine B and C and use symbolic links inside /a
> > pointing to the other SMB mount point, which is a quite common way to do
> > things.