[ale] NFS as a hair-loss enhancer

[Eric Z. Ayers]

Actually, this space may cause problems when you upgrade your system.
We had a situation where 

/home/export *.foo.com (rw)

Worked great in the older release, but after the upgrade, it caused
the directory to be exported read-only.  Changing it to:

/home/export *.foo.com(rw)

without a space between the machine name and the parenthesized options 
fixed the problem.  This occured when upgrading from Redhat 5.2 to
Redhat 6.2.  We were using the kernel NFS implementation both before
and after the upgrade. 

Regards,
-Eric.

Joe Knapka writes:
 > I'm pretty sure the problem was a syntax error in /etc/exports.
 > I had:
 > 
 > /home/export 192.168.1.0/255.255.255.0(rw)
 > 
 > Changing it to:
 > 
 > /home/export 192.168.1.0/255.255.255.0 (rw)
 > 
 > (note extra space)
 > 
 > made everything work (or so it appears).
 > 
 > Thanks,
 > 
 > -- Joe
 > 
 > 
 > Jared Lyvers wrote:
 > > 
 > > I have always edited the following files in order to allow my nfs to work.
 > > ## needed to tell system what to export
 > > /etc/exports
 > >         /dir/export     mysystem(rw)
 > > 
 > > ## needed to tell system what the system is ( NFS will not work here)
 > > /etc/hosts
 > >         192.168.1.2  mysystem.foo.bar   mysystem
 > > 
 > > ## needed to tell system who is allowed to export
 > > /etc/hosts.allow
 > >         portmap:          192.168.1.2:255.255.255.0
 > > 
 > > Hope this helps
 > > 
 > > <<--start snipit--
 > > #I don't know what I did, but suddenly it works. Any insight
 > > #into what might have been the problem is still appreciated.
 > > #
 > > #-- Joe
 > > #
 > > #Joe Knapka wrote:
 > > #
 > > #> Hi, everyone,
 > > #>
 > > #> I know I'm missing something obvious; hopefully the act of
 > > #> sending this email and exposing my ignorance will immediately
 > > #> cause the veil to be drawn from my eyes...
 > > #>
 > > #> I'm trying to install Slackware onto a machine via NFS. My problem
 > > #> is that no matter what I do, my NFS server refuses permission to
 > > #> the client. The contents of hosts.allow and hosts.deny are completely
 > > #> irrelevant, it seems; rpc.mountd always just says:
 > > #>
 > > #> <Some stuff about being unable to resolve the client host name,
 > > #> which is curious since nslookup resolves it just fine>
 > > #> Blocked attempt of <client address> to mount /export
 > > #>
 > > #> and the client says
 > > #>
 > > #> mount: whyme:/export failed. Reason given by server: Permission denied
 > > #>
 > > #> /export is exported to my local net in /etc/exports, exporfs has been
 > > #> run, and (at present) hosts.deny is empty and hosts.allow says:
 > > #>
 > > #> # It's not obvious whether the "rpc." prefix is necessary...
 > > #> portmap: ALL
 > > #> rpc.portmap: ALL
 > > #> mountd: ALL
 > > #> rpc.mountd: ALL
 > > #>
 > > #> This behavior occurs even if rpc.mountd is started in
 > > #> "promiscuous" mode.
 > > #> I have tried every conceivable combination of permissions in
 > > #> hosts.allow and hosts.deny.
 > > #> I have tried mounting from different machines, including the
 > > #> NFS server itself, always with the same exact results. The
 > > #> NFS HOWTO was unhelpful. Can anyone spare a clue?
 > > #>
 > > #> Thanks,
 > > #>
 > > #> -- Joe Knapka
 > > #> (now relocated from west GA to El Paso, TX)
 > > --end snipit-->>
 > > 
 > > --
 > > Do, or do not.  There is no try.  --Yoda
 > > 
 > > Jared Lyvers
 > > System Administrator
 > > Lewis Communications | Birmingham
 > > 205.980.0774 x3047
 > > http://www.lewiscommunications.com/employees/jaredlyvers
 > > 
 > >         |
 > > |__--McGregor--__|
 > >         |
 > >    Jared Lyvers
 > > --
 > > To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
 > 
 > -- Joe Knapka
 > * What happens when a mysterious force meets an inscrutable object?
 > --
 > To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.