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

Aaron S. Joyner aaron at joyner.ws
Sat Jan 20 02:27:14 EST 2007


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', thus
breaking 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 NFS
and 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, which
now 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 distro
he's running (some redhat derivative?) does this.  *shrug*



More information about the TriLUG mailing list