FAQ
I have an issue that is not all that unique, so I'm hoping someone has
done it before.

On the client end I have some very old RedHat based systems. On the
server end is a Windows 2008 system running NFS server software. The
clients mount the server resource as an NFS2 mount but some compliance
issues were discovered with the setup. For various reasons, updating
the client is not an option at this time. The fix the issue, the
server needs to export NFS3 mounts but the clients do not support that
version. As a workaround, I considered adding a third system running
CentOS that would mount the server and re-export it to the clients.
This will mitigate the current issue related to visibility of the
share from certain groups.

It does not appear possible, using the current kernel-based NFS
server, to export an NFS-mounted filesystem. However, it appears that
there is a FUSE NFS project that might work. Does anyone have any
experience with such a setup?

Search Discussions

  • Juergen Gotteswinter at Jul 13, 2010 at 10:22 am
    re-exporting a nfs mount with the kernel nfs server works for me.
    On 07/13/2010 04:01 PM, Kwan Lowe wrote:
    I have an issue that is not all that unique, so I'm hoping someone has
    done it before.

    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup. For various reasons, updating
    the client is not an option at this time. The fix the issue, the
    server needs to export NFS3 mounts but the clients do not support that
    version. As a workaround, I considered adding a third system running
    CentOS that would mount the server and re-export it to the clients.
    This will mitigate the current issue related to visibility of the
    share from certain groups.

    It does not appear possible, using the current kernel-based NFS
    server, to export an NFS-mounted filesystem. However, it appears that
    there is a FUSE NFS project that might work. Does anyone have any
    experience with such a setup?
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Kwan Lowe at Jul 13, 2010 at 10:30 am

    On Tue, Jul 13, 2010 at 10:22 AM, Juergen Gotteswinter wrote:
    re-exporting a nfs mount with the kernel nfs server works for me.
    Did you need to do anything special to get it to work? I am mounting
    an NFS3 share and exporting that same filesystem as NFS2. These are
    the types of errors I get:


    Jul 12 18:07:28 mrmbc01v04 mountd[12194]: authenticated mount request
    from 10.201.54.113:906 for /mnt/nfs_test (/mnt/nfs_test)
    Jul 12 18:07:28 mrmbc01v04 mountd[12194]: Cannot export /mnt/nfs_test,
    possibly unsupported filesystem or fsid= required
  • Mark Roth at Jul 13, 2010 at 11:32 am

    Kwan Lowe wrote:
    I have an issue that is not all that unique, so I'm hoping someone has
    done it before.

    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup. For various reasons, updating
    the client is not an option at this time. The fix the issue, the
    server needs to export NFS3 mounts but the clients do not support that
    version. As a workaround, I considered adding a third system running
    CentOS that would mount the server and re-export it to the clients.
    This will mitigate the current issue related to visibility of the
    share from certain groups.
    <snip>
    You might look at unfs, which can re-export. I used it with glusterfs, so
    as to have a head node.

    mark
  • Ross Walker at Jul 13, 2010 at 12:27 pm

    On Jul 13, 2010, at 10:01 AM, Kwan Lowe wrote:

    I have an issue that is not all that unique, so I'm hoping someone has
    done it before.

    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup. For various reasons, updating
    the client is not an option at this time. The fix the issue, the
    server needs to export NFS3 mounts but the clients do not support that
    version. As a workaround, I considered adding a third system running
    CentOS that would mount the server and re-export it to the clients.
    This will mitigate the current issue related to visibility of the
    share from certain groups.

    It does not appear possible, using the current kernel-based NFS
    server, to export an NFS-mounted filesystem. However, it appears that
    there is a FUSE NFS project that might work. Does anyone have any
    experience with such a setup?
    Can the clients do CIFS mounts of the Windows share?

    -Ross
  • Robert Heller at Jul 13, 2010 at 12:48 pm

    At Tue, 13 Jul 2010 10:01:18 -0400 CentOS mailing list wrote:
    I have an issue that is not all that unique, so I'm hoping someone has
    done it before.

    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup. For various reasons, updating
    the client is not an option at this time. The fix the issue, the
    server needs to export NFS3 mounts but the clients do not support that
    version. As a workaround, I considered adding a third system running
    CentOS that would mount the server and re-export it to the clients.
    This will mitigate the current issue related to visibility of the
    share from certain groups.

    It does not appear possible, using the current kernel-based NFS
    server, to export an NFS-mounted filesystem. However, it appears that
    there is a FUSE NFS project that might work. Does anyone have any
    experience with such a setup?
    It really is NOT a good idea to re-export a network-mounted file system.
    Is there some reason you cannot simply migrate the data on the Windows
    2008 server to a new CentOS system? Note that you can also install
    Samba on the new CentOS system, which will support any MS-Windows
    clients served by the Windows 2008 server.

    One possibity would be to install a virtual CentOS server on the Windows
    2008 server and have it *replace* the NFS server running on the Windows
    2008 server. You would need to map the file systems to be exported as
    local/virtual file systems on the virtual CentOS server.

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    --
    Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
    Deepwoods Software -- Linux Installation and Administration
    http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
    heller at deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
  • Kwan Lowe at Jul 13, 2010 at 1:17 pm

    On Tue, Jul 13, 2010 at 12:48 PM, Robert Heller wrote:
    It really is NOT a good idea to re-export a network-mounted file system.
    Is there some reason you cannot simply migrate the data on the Windows
    2008 server to a new CentOS system? ?Note that you can also install
    Samba on the new CentOS system, which will support any MS-Windows
    clients served by the Windows 2008 server.

    One possibity would be to install a virtual CentOS server on the Windows
    2008 server and have it *replace* the NFS server running on the Windows
    2008 server. ?You would need to map the file systems to be exported as
    local/virtual file systems on the virtual CentOS server.
    Thanks Robert...Unfortunately, changes to the server and client
    require a large effort. The systems are only accessible remotely, are
    in use 24 hours a day for two to three weeks at a time, and making any
    change, even adding a script, requires re-certification.

    Mark - thanks.. I will look at unfs..

    Ross - We considered that option and may consider it if re-exporting a
    share is possible with CIFS.
  • Ross Walker at Jul 13, 2010 at 6:40 pm

    On Jul 13, 2010, at 1:17 PM, Kwan Lowe wrote:
    On Tue, Jul 13, 2010 at 12:48 PM, Robert Heller wrote:

    It really is NOT a good idea to re-export a network-mounted file system.
    Is there some reason you cannot simply migrate the data on the Windows
    2008 server to a new CentOS system? Note that you can also install
    Samba on the new CentOS system, which will support any MS-Windows
    clients served by the Windows 2008 server.

    One possibity would be to install a virtual CentOS server on the Windows
    2008 server and have it *replace* the NFS server running on the Windows
    2008 server. You would need to map the file systems to be exported as
    local/virtual file systems on the virtual CentOS server.
    Thanks Robert...Unfortunately, changes to the server and client
    require a large effort. The systems are only accessible remotely, are
    in use 24 hours a day for two to three weeks at a time, and making any
    change, even adding a script, requires re-certification.

    Mark - thanks.. I will look at unfs..

    Ross - We considered that option and may consider it if re-exporting a
    share is possible with CIFS.
    Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.

    Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?

    You might be painted into a corner here, being forced to upgrade under duress.

    -Ross
  • Kwan Lowe at Jul 13, 2010 at 8:23 pm

    On Tue, Jul 13, 2010 at 6:40 PM, Ross Walker wrote:

    Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.

    Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?

    You might be painted into a corner here, being forced to upgrade under duress.
    It's not specifically NFS, but more related to how the application
    stack was designed. We are essentially working around some 6 year old
    design decisions. When they were built, little thought was placed on
    allowing full access as the systems are on an isolated network. Over
    the years, other systems began to interface to the original
    application. Because one of those systems fall is a compliance target
    system, the original box needs to be compliant also.
  • Ross Walker at Jul 13, 2010 at 9:08 pm

    On Jul 13, 2010, at 8:23 PM, Kwan Lowe wrote:
    On Tue, Jul 13, 2010 at 6:40 PM, Ross Walker wrote:

    Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.

    Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?

    You might be painted into a corner here, being forced to upgrade under duress.
    It's not specifically NFS, but more related to how the application
    stack was designed. We are essentially working around some 6 year old
    design decisions. When they were built, little thought was placed on
    allowing full access as the systems are on an isolated network. Over
    the years, other systems began to interface to the original
    application. Because one of those systems fall is a compliance target
    system, the original box needs to be compliant also.
    Hmmm, maybe the problem isn't necessarily the NFS setup but the interface of the lower trusted systems.

    Maybe developing a bastion host between the trusted and non-trusted networks would solve the compliance issue?

    Separate VLANs, firewall host that uses forward and reverse NAT or possibly application proxy to limit the protocols and the hosts that use them across the trusted network. Detailed logging to a central log host for auditing.

    If done with care it could be done with minimal interruption.

    -Ross
  • Gordon Messmer at Jul 13, 2010 at 7:44 pm

    On 07/13/2010 07:01 AM, Kwan Lowe wrote:
    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup.
    I'm not sure I can help, but I'm very curious. How old are these
    systems, that they don't support NFSv3? And what kind of compliance
    issues? I don't know of any security enhancements that were introduced
    in NFSv3.
  • Kwan Lowe at Jul 13, 2010 at 8:19 pm

    On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmer wrote:
    On 07/13/2010 07:01 AM, Kwan Lowe wrote:
    On the client end I have some very old RedHat based systems. On the
    server end is a Windows 2008 system running NFS server software. The
    clients mount the server resource as an NFS2 mount but some compliance
    issues were discovered with the setup.
    I'm not sure I can help, but I'm very curious. ?How old are these
    systems, that they don't support NFSv3? ?And what kind of compliance
    issues? ?I don't know of any security enhancements that were introduced
    in NFSv3.
    It's a combination of some very old (RH2.1) systems and a rigid
    certification process. In short, once the machines are built it's
    very, very difficult to modify the setup. Not only are they only
    available by a satellite link on only certain days, but the systems
    are critical and don't have maintenance windows. Every few years they
    may get updated
  • Gordon Messmer at Jul 14, 2010 at 7:12 pm

    On 07/13/2010 05:19 PM, Kwan Lowe wrote:
    On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmerwrote:
    I'm not sure I can help, but I'm very curious. How old are these
    systems, that they don't support NFSv3?
    It's a combination of some very old (RH2.1) systems and a rigid
    certification process.
    Red Hat Linux 2.1, from 1995?

    You mentioned "compliance", but not how NFSv3 will help you mean a
    specific need. How will moving the NFSv2 export from Windows 2008 to
    CentOS help you become more "compliant"?
  • Kwan Lowe at Jul 14, 2010 at 9:59 pm

    On Wed, Jul 14, 2010 at 7:12 PM, Gordon Messmer wrote:
    On 07/13/2010 05:19 PM, Kwan Lowe wrote:
    On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmer<yinyang at eburg.com> ?wrote:
    I'm not sure I can help, but I'm very curious. ?How old are these
    systems, that they don't support NFSv3?
    It's a combination of some very old (RH2.1) systems and a rigid
    certification process.
    Red Hat Linux 2.1, from 1995?

    You mentioned "compliance", but not how NFSv3 will help you mean a
    specific need. ?How will moving the NFSv2 export from Windows 2008 to
    CentOS help you become more "compliant"?
    :) I know... believe me...

    The clients cannot be upgraded for several more months, possibly over
    a year from now. They do not support NFS3. The Windows server does
    support NFS2, but per the guidelines, this version is not allowed.
    It's not the NFS protocol itself, but some decisions that were made
    several years ago on how files were placed on the server. They are
    essentially open to the world (i.e., to guest access), but this was
    acceptable at the time because it was on an isolated network and there
    were no other users defined on the system.

    Since we cannot modify the client at this time (i.e., install an NFS3
    capable client), and the underlying issue cannot be solved by changing
    permissions on the server, we considered adding a third server that
    would mount the Windows server then re-export it to the clients. We
    could then lock down the new server to comply with the guidelines.
  • Gordon Messmer at Jul 15, 2010 at 1:29 pm
    I think I'm more confused than before.
    On 07/14/2010 06:59 PM, Kwan Lowe wrote:
    The clients cannot be upgraded for several more months, possibly over
    a year from now. They do not support NFS3.
    Is that to say that they are Red Hat 2.1, from 1995? (not RHEL 2.1)?
    The Windows server does
    support NFS2, but per the guidelines, this version is not allowed.
    So NFS2 is *not* allowed on Windows 2008, but it *is* allowed on CentOS?
    Since we cannot modify the client at this time (i.e., install an NFS3
    capable client), and the underlying issue cannot be solved by changing
    permissions on the server, we considered adding a third server that
    would mount the Windows server then re-export it to the clients.
    So you can't configure the Windows server to export data only to the
    client PCs, but you can configure to export data only to the CentOS host?
  • Gordon Messmer at Jul 19, 2010 at 1:07 am

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJul 13, '10 at 10:01a
activeJul 19, '10 at 1:07a
posts16
users6
websitecentos.org
irc#centos

People

Translate

site design / logo © 2018 Grokbase