NFS Exporting a samba share - NFS

This is a discussion on NFS Exporting a samba share - NFS ; 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, ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: NFS Exporting a samba share

  1. NFS Exporting a samba share

    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.

    I have been looking at permissions and all the mount points on the
    server and they are all owned by the same owner as the rest of /a, so
    it should be fine.

    The server is running Mandrake 7.x (iirc) and the client is running
    Solaris 9. The servers hosting the samba shares are all Windows
    2000/XP machines.

  2. Re: NFS Exporting a samba share

    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.
    Try exporting the samba mounts. This assumes the samba file system
    will allow NFS exporting.

  3. Re: NFS Exporting a samba share

    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.

    > 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
    mounts and including NFS mounts. Alternatively, set up the SMB mount to be
    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.



  4. Re: NFS Exporting a samba share

    "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.

    > 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.


  5. Re: NFS Exporting a samba share

    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.


  6. Re: NFS Exporting a samba share


    "Mike Eisler" wrote in message
    news:36f0f19f.0407070450.511d1f0c@posting.google.c om...

    > > > 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.
    >
    > > 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?


    That's a very good question. It's a potential problem with security and
    file-locking craziness, which NFS handles by saying "You can't do that you
    silly goose". But the file ownership, file permissions, and file locking of
    SMB is far more handled, at least for Samba servers and ASU servers, by
    programs in userspace, not by kernel fun and joy. You described some of the
    kernel-level fun and joy for NFS in your bits that I snipped. So while the
    security and file-locking issues exist, SMB servers like Samba just go ahead
    and provide them anyway. Also, SMB is nowhere near so vulnerable to the
    sorts of failures NFS experiences when either a client *or* a server loses
    track of its partner, such as during an extended network interruption or
    power failures, and refuses to let go of the old mount and require rebooting
    of *both* machines, especially with having to go in by hand and remove
    entries from the "rmtab" file. Add in a middle NFS server doing transitive
    file mounting and you're asking for your head on a platter, carved up fine
    and scatterd with onion rings.

    But in places like the Windows world, you can't mount one directory inside
    another, so you do avoid some of the potential delights.

    > > 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.




  7. Re: NFS Exporting a samba share


    "Paul Richards" wrote in message
    news:a1138db3.0407071239.2379816a@posting.google.c om...

    > 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?


    I got it working just fine under SunOS 4.x years ago. If you're using Samba,
    it should work fine unless Sun has done oddnesses to their OS since then.
    Mind you, they may have done oddnesses to it. That's why I pointed out the
    alternative of using symbolic links instead of mount points to point to
    another location.

    Creating a robust, flexible structure for mounting things appropriately
    inside your network can be lots of fun to get right. And in fact,
    personally, I'd use symbolic links to distinct mount points inside the first
    mounted directory to make things work more flexibly and avoid running an
    additional file server on the intermediate client.



  8. Re: NFS Exporting a samba share

    paul.richards@gmail.com (Paul Richards) wrote in message news:...
    > > > 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


    Probablt because Samba servers are SMB servers engineered for
    Windows clients, and Windows clients don't care about
    POSIX issues.

    > 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


    An in-kernel SMB client? for Solari s9. I knew there
    were couple for Linux. Wow, I guess there's no need for NFSv4
    now. :-)


    > handles the unix file permissions. Does anyone know if my system will
    > be happy having home directories mounted over samba?
    >


  9. Re: NFS Exporting a samba share

    Mike Eisler wrote:

    >> 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

    >
    > An in-kernel SMB client? for Solari s9. I knew there
    > were couple for Linux. Wow, I guess there's no need for NFSv4
    > now. :-)


    Especially because AFS is available for Solaris, Linux, Windows, and MacOS
    X, allowing a far more secure authentication structure and robust file
    access for remotely connected sites.




  10. Re: NFS Exporting a samba share

    "Nico Kadel-Garcia" wrote in message news:...
    > Mike Eisler wrote:
    >
    > >> 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

    > >
    > > An in-kernel SMB client? for Solari s9. I knew there
    > > were couple for Linux. Wow, I guess there's no need for NFSv4
    > > now. :-)

    >
    > Especially because AFS is available for Solaris, Linux, Windows, and MacOS
    > X, allowing a far more secure authentication structure and robust file
    > access for remotely connected sites.


    Kerberos V5 authentication, integrity, and
    privacy for NFS has been shipping since 1998.

  11. Re: NFS Exporting a samba share


    "Mike Eisler" wrote in message
    news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
    > "Nico Kadel-Garcia" wrote in message

    news:...
    > > Mike Eisler wrote:
    > >
    > > >> 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
    > > >
    > > > An in-kernel SMB client? for Solari s9. I knew there
    > > > were couple for Linux. Wow, I guess there's no need for NFSv4
    > > > now. :-)

    > >
    > > Especially because AFS is available for Solaris, Linux, Windows, and

    MacOS
    > > X, allowing a far more secure authentication structure and robust file
    > > access for remotely connected sites.

    >
    > Kerberos V5 authentication, integrity, and
    > privacy for NFS has been shipping since 1998.


    Friend, have you ever *tried* to integrate Kerberos into NFS in the wild?
    It's..... pretty painful, at least the last couple of times *I* tried it.
    And you missed the "robust" part. There is still no fix for the "if you lose
    network connections of a hard-mounted NFS directory, you often need to
    reboot both the server and the client to clean up the mess" problem. This
    has been true for many years, and remains unchanged, especially since a lot
    of NFS clients have built-in antique sources and lack these resources but
    are expected to continue operating as modern servers.

    OSF/1, anyone?



  12. Re: NFS Exporting a samba share

    "Nico Kadel-Garcia" wrote in message news:...
    > "Mike Eisler" wrote in message
    > news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
    > > "Nico Kadel-Garcia" wrote in message

    > news:...
    > > > Mike Eisler wrote:
    > > >
    > > > >> 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
    > > > >
    > > > > An in-kernel SMB client? for Solari s9. I knew there
    > > > > were couple for Linux. Wow, I guess there's no need for NFSv4
    > > > > now. :-)
    > > >
    > > > Especially because AFS is available for Solaris, Linux, Windows, and

    > MacOS
    > > > X, allowing a far more secure authentication structure and robust file
    > > > access for remotely connected sites.

    > >
    > > Kerberos V5 authentication, integrity, and
    > > privacy for NFS has been shipping since 1998.

    >
    > Friend, have you ever *tried* to integrate Kerberos into NFS in the wild?


    Yes. I've even shipped implementations of it.

    ANyway, what do you mean by integrating Kerberos into NFS? Either
    the NFS client and server support RFC 2203 or they don't. Only one
    commerically supported UNIX client supports the RFC today, and
    several servers.

    > It's..... pretty painful, at least the last couple of times *I* tried it.


    Do tell.

    > And you missed the "robust" part. There is still no fix for the "if you lose
    > network connections of a hard-mounted NFS directory, you often need to
    > reboot both the server and the client to clean up the mess" problem. This


    This is somethig I've never personally experienced, though I've tended
    to confine myself to good clients. Indeed, in the early days of NFS,
    my desktop ran completely diskless. In those days servers were less
    reliable than clients, and hard mounts meant the desk top was frozen.
    Then the server came back, the desktop came back to life, and
    everything continued. No mess.

    Since then, at least one client has added a forced unmount option.

    > has been true for many years, and remains unchanged, especially since a lot
    > of NFS clients have built-in antique sources and lack these resources but
    > are expected to continue operating as modern servers.
    >
    > OSF/1, anyone?


    OSF/1 is shipped by who now?

    Anyway, I've nothing against AFS, except that people can't find
    anyone to provide reliable commerical support for it now that IBM is
    EOLing the commercial product. I wish OpenAFS all the best, but I fear
    that just with the original CMU license, the
    OpenAFs license will prevent it from taking hold. It was because of
    the original license terms that AFS never made significant inroads, whereas,
    NFS source code, for $25K a copy, and an optional $250K buy out of the
    royalties, made it deal that no could refuse.

    I find it interesting that people are looking running CIFS on UNIX/Linux
    client and the file server.

  13. Re: NFS Exporting a samba share

    spamisevi1@yahoo.com (Mike Eisler) wrote in message news:<36f0f19f.0407081629.6d92b402@posting.google.com>...
    > paul.richards@gmail.com (Paul Richards) wrote in message news:...
    > > > > 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

    >
    > Probablt because Samba servers are SMB servers engineered for
    > Windows clients, and Windows clients don't care about
    > POSIX issues.
    >
    > > 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

    >
    > An in-kernel SMB client? for Solari s9. I knew there
    > were couple for Linux. Wow, I guess there's no need for NFSv4
    > now. :-)


    Sorry actually.. I was wrong. The "Samba support" is has is only for
    serving shares. It cannot mount shares onto the filesystem..

    >
    >
    > > handles the unix file permissions. Does anyone know if my system will
    > > be happy having home directories mounted over samba?
    > >


  14. Re: NFS Exporting a samba share

    Mike Eisler wrote:
    > "Nico Kadel-Garcia" wrote in message
    > news:...
    >> "Mike Eisler" wrote in message
    >> news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
    >>> "Nico Kadel-Garcia" wrote in message

    >> news:...
    >>>> Mike Eisler wrote:
    >>>>
    >>>>>> 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
    >>>>>
    >>>>> An in-kernel SMB client? for Solari s9. I knew there
    >>>>> were couple for Linux. Wow, I guess there's no need for NFSv4
    >>>>> now. :-)
    >>>>
    >>>> Especially because AFS is available for Solaris, Linux, Windows,
    >>>> and

    >> MacOS
    >>>> X, allowing a far more secure authentication structure and robust
    >>>> file access for remotely connected sites.
    >>>
    >>> Kerberos V5 authentication, integrity, and
    >>> privacy for NFS has been shipping since 1998.

    >>
    >> Friend, have you ever *tried* to integrate Kerberos into NFS in the
    >> wild?

    >
    > Yes. I've even shipped implementations of it.
    >
    > ANyway, what do you mean by integrating Kerberos into NFS? Either
    > the NFS client and server support RFC 2203 or they don't. Only one
    > commerically supported UNIX client supports the RFC today, and
    > several servers.


    Getting a Kerberized login system actually running can be extremely painful.
    Most UNIX vendors do not keep open source tools like this up to date in
    their distributions, and thus tend to lack feature sets or compatibility
    with other UNIX or other OS distributions with even slightly different
    versions. This problem occurs with both Kerberos and NFS releases across
    multipls OS releases. If you take advantage of subtle configurations to make
    things work the way you want (such as using an NIS domain name that does not
    match your network's default domain name, or using hostnames that are not
    fully qualified because of people's old software that uses "$HOSTNAME" =
    "non-fully-qualified-hostname" sorts of statements, it quickly becomes a
    nightmare. And Kerberos used to be pretty fascist about insisting that the
    first hostname returned by various "gethostby*" functions actually match
    both the local $HOSTNAME and be a fully-qualified-hostname.

    In fact, at the time, you could not *compile* Kerberos on a system that did
    not have a FQHN and have its FQHN first in the normally setup /etc/hosts
    lines. It's not required anywhere in the RFC's, but there was a little
    compilation step that recorded the hostname for logging purposes, which
    broke on this and required the entire thing to be recompiled from scratch
    due to unnecessary creation of a TIMESTAMP file at compile time, designed to
    force complete recompilation from scratch instead of permitting partial
    compilation and Makefile dependencies in the development phase.

    Oh, yeah, I've been through this with Solaris, OSF/1, and maybe a dozen
    Linux variants. The Linux folks, fortunately, tend to clean out this kind of
    silliniess.

    >> It's..... pretty painful, at least the last couple of times *I*
    >> tried it.

    >
    > Do tell.


    See above. Compiling a new set of NIS tools is even worse, and more
    dangerous, because so much of it is women into libc in the Solaris world.
    Recent versions of NIS may finally incorporate these features for Solaris
    releases, but a lot of work places these days have a stack of old Solaris
    2.6 and up systems. Integrating newer releases into those environments is
    extremely difficult without turning off the more sophisticated
    functionality, especially with Sun's long-standing practice of forcing OS
    upgrades by only releasing the new OS's with new architectures. Backporting
    the feature sets is..... also painful.

    >> And you missed the "robust" part. There is still no fix for the "if
    >> you lose network connections of a hard-mounted NFS directory, you
    >> often need to reboot both the server and the client to clean up the
    >> mess" problem. This

    >
    > This is somethig I've never personally experienced, though I've tended
    > to confine myself to good clients. Indeed, in the early days of NFS,
    > my desktop ran completely diskless. In those days servers were less
    > reliable than clients, and hard mounts meant the desk top was frozen.
    > Then the server came back, the desktop came back to life, and
    > everything continued. No mess.


    I've run into it fairly frequently, for years. It's not so bad if you use
    auto-mounting, and if you don't have processes that auto-generate files on
    the hard-mounted or auto-mounted system frequently, and if your disconnect
    time is quite short.

    But if someone accidentally unplugs a fiber for an hour on a system logging
    utility that generates files on an NFS mount every minute, you're
    definitively screwed on both ends, at least in my experience. It also gets
    much worse if you have the old AMD based automount tools, rather than the
    more recent autofs tools, that do the symbolic link whackiness to auto-mount
    things under /tmp_mnt and create symbolic links to them.

    > Since then, at least one client has added a forced unmount option.


    I can believe that. It's also deadly in when a process is holding an NFS
    mount point open: in both the Linux and Solaris world, "fuser -m mountpoint"
    is your friend for finding these and putting a bullet through them.

    >> has been true for many years, and remains unchanged, especially
    >> since a lot of NFS clients have built-in antique sources and lack
    >> these resources but are expected to continue operating as modern
    >> servers.
    >>
    >> OSF/1, anyone?

    >
    > OSF/1 is shipped by who now?


    It's not shipped, anymore. DEC's previous releases of it for the Alpha got
    taken over by Compaq, then by HP, and HP has end-of-lifed it, partially
    because Alpha support and development is also pretty dead since the Alpha
    technology got bought out by Intel in the wake of DEC's collapse.

    But it's still heavily used in a lot of server class file server
    environments. AdvFS running on SMP 64-bit Alphas does quite well with
    extremely large amounts of RAM and extremely large amounts of disk, in the
    many Terabyte range.

    > Anyway, I've nothing against AFS, except that people can't find
    > anyone to provide reliable commerical support for it now that IBM is
    > EOLing the commercial product. I wish OpenAFS all the best, but I fear


    Ohhh, shoot. I liked AFS, and had good success with WAN deployments of
    OpenAFS over Linux/Windows setups.

    > that just with the original CMU license, the
    > OpenAFs license will prevent it from taking hold. It was because of
    > the original license terms that AFS never made significant inroads,
    > whereas,
    > NFS source code, for $25K a copy, and an optional $250K buy out of the
    > royalties, made it deal that no could refuse.


    Corporations couldn't refuse. Individuals poking around, however, could not
    even get started.

    > I find it interesting that people are looking running CIFS on
    > UNIX/Linux
    > client and the file server.


    Yeah, I caught a presentation by Jeff Schiller of MIT on the fun and games
    of CIFS authentication a few years back. It was pretty nifty, and as CPU
    overhead has continued to drop in price, it's become a much more acceptable
    overhead. But I've never had the opportunity or incentive to get it running.

    SMB is looking better and better for UNIX/Linux access. The resistance to
    failures of occasional disconnections, and its ubiquity in the Windows
    world, coupled with the helpful "reset all files in this directory to be
    owned by foo with permissions bar" that is trivial to set up in the Samba
    configurations is getting more and more appealing.



  15. Re: NFS Exporting a samba share

    "Nico Kadel-Garcia" wrote in message news:...
    > > ANyway, what do you mean by integrating Kerberos into NFS? Either
    > > the NFS client and server support RFC 2203 or they don't. Only one
    > > commerically supported UNIX client supports the RFC today, and
    > > several servers.

    >
    > Getting a Kerberized login system actually running can be extremely painful.


    Well there's much more to getting NFS to authenticate with Kerberos
    that compiling a wad code from MIT or Heimdal. True end to
    end authentication requires kernel support. Most people, unless
    they operating systems implementors won't, and probably shouldn't
    bother to take it on.

    > Most UNIX vendors do not keep open source tools like this up to date in
    > their distributions, and thus tend to lack feature sets or compatibility
    > with other UNIX or other OS distributions with even slightly different
    > versions. This problem occurs with both Kerberos and NFS releases across


    Interoperability issues will always come up. This isn't
    confined to Kerberos or NFS.

    > multipls OS releases. If you take advantage of subtle configurations to make
    > things work the way you want (such as using an NIS domain name that does not
    > match your network's default domain name, or using hostnames that are not
    > fully qualified because of people's old software that uses "$HOSTNAME" =
    > "non-fully-qualified-hostname" sorts of statements, it quickly becomes a
    > nightmare. And Kerberos used to be pretty fascist about insisting that the


    Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
    based on the FQDN returned by DNS.

    have you actually used an NFS/Kerberos V5 stack, or are you
    casting theory?

  16. Re: NFS Exporting a samba share

    Mike Eisler wrote:

    >> multipls OS releases. If you take advantage of subtle configurations
    >> to make things work the way you want (such as using an NIS domain
    >> name that does not match your network's default domain name, or
    >> using hostnames that are not fully qualified because of people's old
    >> software that uses "$HOSTNAME" = "non-fully-qualified-hostname"
    >> sorts of statements, it quickly becomes a nightmare. And Kerberos
    >> used to be pretty fascist about insisting that the

    >
    > Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
    > based on the FQDN returned by DNS.
    >
    > have you actually used an NFS/Kerberos V5 stack, or are you
    > casting theory?


    Harsh, harsh experience with older NFS/Kerberos implementations in very
    heterogeneous configurations. Unless they've added something since then,
    Kerberos uses the various "gethostby" functions in libc to try to determine
    the canonical hostname, and actually uses the first entry returned as the
    "canonical" name. And unfortunately, you can't just assert that "DNS gives
    the canonical hostname". The various actual functions can and do give
    multiple answers, depending on the system's pre-defined "HOSTNAME", the
    contents of /etc/hosts, the NIS published "hosts" table, the contents of
    /etc/resolv.conf to actually decide where to do the DNS lookup that you
    mentioned, etc. DNS is in fact rarely configured to be their first source of
    IP/HOSTNAME resolution, the first source is usually /etc/hosts. And the
    function then typically returns all these names in order of how they were
    resolved, namely from /etc/hosts first. This is why it's such fun to say
    "OK, I've set hostname to be 'my.domain.com', but because I can get away
    with it I put "127.0.0.2 my my.domain.com my.offsite-domain.com' in
    /etc/hosts.

    It's completely legal in DNS and these address functions to do this,
    although it's usually considered a bad idea because such shortend hostnames
    are not necessarily unique in even a modest sized network and can cause
    fascinating, fascinating confusions for all involved. The main excuse to do
    it is to simplify your life if you swap a machine from one DNS domain to
    another frequently, and you want to be consistent about using a short alias
    and non FQHN for your system-dependent software tools in both domains
    without resetting your HOSTNAME. You can't safely just switch HOSTNAME at
    whim: you'll break X-servers and X-clients running locally on your machine.
    And ghods forbid you change HOSTNAME while you've got an NFS mount as client
    or server! Changing HOSTNAME is usually accompanied by bringing the system
    down to a single user mode to avoid exactly that sort of fun and games.

    In a Kerberized environment, you probably shouldn't be hopping back and
    forth between domains anyway, but I think you can see where it can get quite
    complex to straighten out such joys and delights.



  17. Re: NFS Exporting a samba share

    "Nico Kadel-Garcia" wrote in message news:...
    > Mike Eisler wrote:
    >
    > >> multipls OS releases. If you take advantage of subtle configurations
    > >> to make things work the way you want (such as using an NIS domain
    > >> name that does not match your network's default domain name, or
    > >> using hostnames that are not fully qualified because of people's old
    > >> software that uses "$HOSTNAME" = "non-fully-qualified-hostname"
    > >> sorts of statements, it quickly becomes a nightmare. And Kerberos
    > >> used to be pretty fascist about insisting that the

    > >
    > > Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
    > > based on the FQDN returned by DNS.
    > >
    > > have you actually used an NFS/Kerberos V5 stack, or are you
    > > casting theory?

    >
    > Harsh, harsh experience with older NFS/Kerberos implementations in very


    Which NFS/Kerberos V5 stack have you used?

    > heterogeneous configurations. Unless they've added something since then,
    > Kerberos uses the various "gethostby" functions in libc to try to determine
    > the canonical hostname, and actually uses the first entry returned as the
    > "canonical" name. And unfortunately, you can't just assert that "DNS gives


    Yes indeed, you are casting theory.

  18. Re: NFS Exporting a samba share

    Nico Kadel-Garcia wrote:

    > Yeah, I caught a presentation by Jeff Schiller of MIT on the fun and games
    > of CIFS authentication a few years back. It was pretty nifty, and as CPU
    > overhead has continued to drop in price, it's become a much more acceptable
    > overhead. But I've never had the opportunity or incentive to get it running.
    >
    > SMB is looking better and better for UNIX/Linux access. The resistance to
    > failures of occasional disconnections, and its ubiquity in the Windows
    > world, coupled with the helpful "reset all files in this directory to be
    > owned by foo with permissions bar" that is trivial to set up in the Samba
    > configurations is getting more and more appealing.


    Funny you should say this, I've just finished adding the mknod call
    into the Samba UNIX extensions that should allow the Linux CIFS client
    to correctly mount peoples home directories case-sensitively and be
    able to create unix domain socket files - thus allowing KDE etc to work
    in a Samba-shared home directory.

    I'm planning to give a talk on using SMB for UNIX to UNIX filesharing
    (RFS reborn anyone ? :-) at both the CIFS and NFS conferences this year.

    Jeremy.



  19. Re: NFS Exporting a samba share

    Mike Eisler wrote:
    > "Nico Kadel-Garcia" wrote in message
    > news:...
    >> Mike Eisler wrote:
    >>
    >>>> multipls OS releases. If you take advantage of subtle
    >>>> configurations to make things work the way you want (such as using
    >>>> an NIS domain name that does not match your network's default
    >>>> domain name, or using hostnames that are not fully qualified
    >>>> because of people's old software that uses "$HOSTNAME" =
    >>>> "non-fully-qualified-hostname" sorts of statements, it quickly
    >>>> becomes a nightmare. And Kerberos used to be pretty fascist about
    >>>> insisting that the
    >>>
    >>> Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
    >>> based on the FQDN returned by DNS.
    >>>
    >>> have you actually used an NFS/Kerberos V5 stack, or are you
    >>> casting theory?

    >>
    >> Harsh, harsh experience with older NFS/Kerberos implementations in
    >> very

    >
    > Which NFS/Kerberos V5 stack have you used?


    Like I said, it's been a while. This level of adventurous analysis was going
    in with the latest MIT Kerberos release and Solaris 2.5 and SunOS 4.1.x. I
    took another shot at it about 5 years ago, and had too many problems getting
    it to interoperate well with the Windows systems, then took another shot at
    it maybe 3 years ago and couldn't get the buy in to make the corporate wide
    changes.

    Like I said, been there, done that. If both have evolved since then, fine,
    but most sites these days use FQHN as their $HOSTNAME, and as their default
    entries in /etc/hosts just as a matter of best practices.

    >> heterogeneous configurations. Unless they've added something since
    >> then, Kerberos uses the various "gethostby" functions in libc to try
    >> to determine the canonical hostname, and actually uses the first
    >> entry returned as the "canonical" name. And unfortunately, you can't
    >> just assert that "DNS gives

    >
    > Yes indeed, you are casting theory.


    No, I actually read the damn code. Have they changed it since then? It was
    particularly irritating with the "I insist on having an FQHN in order to log
    what machine compiled this code, and I won't let you recompile it except
    from scratch because I have fiendishly installed a timestamp in the Makefile
    structure to force onbly complete recompilations, moo-ha-ha!"

    Look, friend, don't call it "casting theory" when someone's actually tried
    to get the systems to work together and run into the ussue.



  20. Re: NFS Exporting a samba share

    "Nico Kadel-Garcia" wrote in message news:<-IednYCpvp46qGjdRVn_iw@comcast.com>...
    > > Which NFS/Kerberos V5 stack have you used?

    >
    > Like I said, it's been a while. This level of adventurous analysis was going
    > in with the latest MIT Kerberos release and Solaris 2.5 and SunOS 4.1.x. I
    > took another shot at it about 5 years ago, and had too many problems getting
    > it to interoperate well with the Windows systems, then took another shot at
    > it maybe 3 years ago and couldn't get the buy in to make the corporate wide
    > changes.

    [...]
    > > Yes indeed, you are casting theory.

    [...]
    > Look, friend, don't call it "casting theory" when someone's actually tried
    > to get the systems to work together and run into the ussue.


    Adding end to end Kerberos V5 authenticaton requires modifying the
    NFS client and server, i.e. kernel work.

    5 years ago, the only systems that support NFS w/ Kerberos were Solaris
    and a couple of Windows NFS clients. And the Solaris implementation
    didn't have DNS issues you note (though admittedly, the MIT base
    much of the code it used did. Sun fixed it. I know, because
    I led the folks who wrote the code). And SunOS 4.1.x never had Kerberos
    authentication it is NFS client or server. Etc.

    So at best, we are talking about something different. At
    worst, if you are claiming that 5 years ago you tried it,
    and can't identify the one NFS server that had it, and
    misidentified SunOS 4.1.x as having it, then you didn't try it.

    NFS implementations that adhere to the RFCs noted
    below have no inferiority complex when it comes to strong
    authentication, privacy, and integrity.

    -mre (co-author, RFC 2203, author RFC 2623, which
    describe the protocols needed for adding Kerberos
    V5 authentication to NFSv4).

+ Reply to Thread