[TriLUG] Access to remote linux files and folders...
dsandif
dsandif at email.unc.edu
Sun Jan 21 15:14:25 EST 2007
Aaron S. Joyner wrote:
> 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*
>
Thanks Aaron & to all who replied. I will give all of these suggestions
and advice a try and get back to you all. Keep them coming!
D-
More information about the TriLUG
mailing list