At 09:37 PM 4/20/2010, Adam Vande More wrote:
>On Tue, Apr 20, 2010 at 4:53 PM, wrote:
>
>>
>> I'm not certain what an RPC connection is, but I assume it's some type of
>> flow of data.
>>
>> Nothing referring to RPC appears in either machine's logs. Not a lot of
>> activity occurs on the file se
On Tue, Apr 20, 2010 at 4:53 PM, wrote:
>
> I'm not certain what an RPC connection is, but I assume it's some type of
> flow of data.
>
> Nothing referring to RPC appears in either machine's logs. Not a lot of
> activity occurs on the file server at 192.168.0.244. It's primary purpose
> in life
I'm not certain what an RPC connection is, but I assume it's some type of flow
of data.
Nothing referring to RPC appears in either machine's logs. Not a lot of
activity occurs on the file server at 192.168.0.244. It's primary purpose in
life is to act as a file server for the machine at 19
Do you have anything relating to RPC connections inbound on the server logs?
It may also be time to look at which version of FBSD you are running.
On 20 April 2010 19:06, wrote:
>
> I deleted the unnecessary line from the /etc/exports file and rebooted both
> machines. Connecting from the clie
I deleted the unnecessary line from the /etc/exports file and rebooted both
machines. Connecting from the client to the server using an "/sbin/mount_nfs
192.168.0.244:/usr/home1 /home1" command took forever . . . well, somewhere
between a half-hour and an hour. It used to be speedy. Nothing
Peter,
The two lines shouldn't create a conflict, but it would seem to me to be
more normal to append the second IP after the first, e.g.:
/usr/home1 -maproot=root 192.168.0.252, 192.168.0.253
On the other hand, if the 253 machine doesn't need access it would be wise
to remove the second
192.168.0.244's /etc/exports file says:
/usr/home1 -maproot=root 192.168.0.252
/usr/home1 -maproot=root 192.168.0.253
192.168.0.252 is the machine that should have access to 192.168.0.244's drive,
but was having difficulty obtaining it. I'm kind of surprised to see the entry
fo
What information is contained in the /etc/exports file on the NFS server? If
that changed between NFS Server restarts that _could_ be the cause.
Also, has there been any simultaneous change in the network across which the
servers speak? Especially with regard to port 111.
On 19 April 2010 15:38
I rebooted the server at 192.168.0.244 and the mount_nfs command miraculously
engaged.
---
At 10:38 AM 4/19/2010, pe...@vfemail.net wrote:
>I have two servers funning FreeBSD. For the past four years, an:
>
>/sbin/mount_nfs 192.168.0.244:/usr/home1 /home1
>
>command has successfull
I have two servers funning FreeBSD. For the past four years, an:
/sbin/mount_nfs 192.168.0.244:/usr/home1 /home1
command has successfully allowed one server access to data on the other
server's hard drive.
This morning, following reboots of both servers, the mount_nsf command fails,
r
I have two servers funning FreeBSD. For the past four years, an:
/sbin/mount_nfs 192.168.0.244:/usr/home1 /home1
command has successfully allowed one server access to data on the other
server's hard drive.
This morning, following reboots of both servers, the mount_nsf command fails,
r
11 matches
Mail list logo