[ale] NFS as a hair-loss enhancer
Dow Hurst
dhurst at kennesaw.edu
Wed Jul 5 11:43:54 EDT 2000
Is there a place on the web where developers of the NFS code post their
docs on the code? Do you have to read the code to pick this up? I have
figured out the nuances of the IRIX NFS implementation but haven't
studied on the Linux NFS yet. I would think there would be a NFS
standard to follow for the format of the /etc/exports file. Maybe there
is a place for a "Linux current file formats website" project. Thanks,
Dow
Joe Knapka wrote:
>
> Hmm. Possibly there is a version issue here. I shall experiment a bit
> more.
>
> -- Joe
>
> "Eric Z. Ayers" wrote:
> >
> > 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.
>
> -- 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.
--
__________________________________________________________
Dow Hurst Office: 770-499-3428
Systems Support Specialist Fax: 770-423-6744
1000 Chastain Rd.
Chemistry Department SC428 Email:dhurst at kennesaw.edu
Kennesaw State University Dow.Hurst at mindspring.com
Kennesaw, GA 30144
*********************************
*Computational Chemistry is fun!*
*********************************
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
More information about the Ale
mailing list