[TriLUG] Access to remote linux files and folders...

[jonc at nc.rr.com]

I've got an NFS/Automount cheatsheet that I've been using for years....
  http://www.trilug.org/~jonc/nfs/nfs_nis_automount.txt

Hope it helps.

Jon Carnes

----- Original Message -----
From: "Aaron S. Joyner" <aaron at joyner.ws>
Date: Saturday, January 20, 2007 2:27 am
Subject: Re: [TriLUG] Access to remote linux files and folders...
To: Triangle Linux Users Group discussion list <trilug at trilug.org>

> dsandif wrote:
> > More to clarify here,
> > 
> > I am are trying to simply mount file systems over the net.
> > 
> > This is what I would like:
> > 
> > Set up hard mounts in the fstab, & have these correctly mounted when
> > ever we boot the machines.
> > 
> > Now, unfortunately, something is screwed up in the mounting 
> process, but
> > I do not know what.
> > I seem to have to boot and reboot numerous times, back and forth, 
> before> the mounting properly takes place.
> > It's as if a system process is not turned on, and when it fails it
> > locks  out any mounting from other computers,
> > even though officially they are supposed to be able to mount 
> those files.
> > 
> > These command lines here probably can go into a boot startup script,
> > 
> > /etc/rc.d/init.d/portmap stop
> > /etc/rc.d/init.d/nfs stop
> > /etc/rc.d/init.d/portmap start
> > /etc/rc.d/init.d/nfs start
> > 
> > but I am not sure which. I don't think these commands are not the 
> problem,> 
> > thanks again to all,
> 
> I'm going to take a while guess from the assembled information 
> here, and
> say that your problem is that not all of the machines are available at
> the same time.  Simplifying your previous example a little, lets 
> say you
> have two machines, 'apples' and 'oranges'.  Each of these machines has
> an /etc/fstab that mounts /shared_foo from the other machine, into
> /mnt/<mach_name>/shared_foo.  For example, on 'apples', you would see
> this /etc/fstab entry:
> 
> oranges:/shared_foo  /mnt/oranges/shared_foo  nfs defaults 0 1
> 
> The problem arises when you attempt to power off both of these 
> machines,and then power them back on.  Let's say for the sake of 
> argument you
> turn on 'apples' first.  As part of 'apples' booting, it will 
> attempt to
> mount oranges:/shared_foo.  Of course, because 'oranges' isn't online
> yet, this operation fails.  Thus, when you try to look at the
> filesystems on 'apples' later, you will discover that
> /mnt/oranges/shared_foo/ is empty.
> 
> On the other hand... when 'oranges' boots, it will find NFS on 
> 'apples'is nicely up and running, and mount the share accordingly.  
> You will see
> files in /mnt/apples/shared_foo/.
> 
> Presumably, you then being to troubleshoot.  As described above, 
> you run
> the following commands on 'apples':
> 
> for x in stop start; do
>  for y in portmap nfs; do
>    service $y $x;
>  done;
> done;
> 
> This of course ungracefully shuts down the NFS server on 'apples', 
> thusbreaking the mount 'oranges' successfully established with it when
> 'oranges' booted.  This also has the side benefit that when the NFS
> server on 'apples' restarts, it retries the nfs mounts from 
> /etc/fstab*and is then able to mount the shares on 'oranges', 
> exibiting what you
> described earlier as "switching the problem to the local box".
> 
> The simple short-term fix to this problem, is instead of restarting 
> NFSand portmap on 'oranges', is to simply run this command on 
> 'apples':mount /mnt/oranges/shared_foo
> 
> This will cause 'apples' to attempt to make it's NFS mount again, 
> whichnow that 'oranges' is live, should succeed with out error.
> 
> The better long-term solution to this problem is to implement 
> automount, but a full description of automount is outside the scope 
> of this email.
> Getting it setup is left as an exercise to the reader.
> 
> Aaron S. Joyner
> 
> 
> * - For reference, I'm stretching the truth here for simplicity.  On
> your average system, with simple init scripts, it's doesn't work this
> way.  I think more likely the OP has left something out of his
> troubleshooting steps like, "I rebooted the entire machine and now it
> works on that machine, and not the other", but I'm giving the 
> benefit of
> the doubt here.  You *could* implement this as part of the
> shutdown/startup scripts to do a `mount -a`, and maybe what ever 
> distrohe's running (some redhat derivative?) does this.  *shrug*
> -- 
> TriLUG mailing list        : 
> http://www.trilug.org/mailman/listinfo/trilugTriLUG Organizational 
> FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>