Nп/п : 36 из 100
 От   : William Unruh                       2:5075/128        22 авг 23 13:16:23
 К    : David W. Hodgins                                      22 авг 23 16:19:02
 Тема : Re: nfs mounting not working
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 1@dont-email.me> 93c2a2c5
@REPLY: <op.19saisraa3w0dxdave@hodgins.homeip.net>
5c07ea32
@REPLYADDR William Unruh <unruh@invalid.ca>
@REPLYTO 2:5075/128 William Unruh
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me> <op.19k6jruea3w0dxdave@hodgins.homeip.net>
1@dont-email.me> <op.19qfn1g9a3w0dxdave@hodgins.homeip.net> 1@dont-email.me>
<op.19saisraa3w0dxdave@hodgins.homeip.net>
@TZUTC: -0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
Thanks will try that if it occurs again. The reason I suspect the server
is that it occured to at least two clients. On the one client I guess it
had been rebooted and had mounted nothing from the server. On the second
client, it had not been rebooted, and nfs worked fine, until I unmounted
one of the partition, and then on remount, it had the same problem.

I finally and accidentally did something to the server, and everything
started working again ( the clients all remouted without problems). of
course I did not notice what I did. 


On 2023-08-16, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Wed, 16 Aug 2023 13:31:35 -0400, William Unruh <unruh@invalid.ca> wrote:
>
>> On 2023-08-15, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>>> On Tue, 15 Aug 2023 13:46:06 -0400, William Unruh <unruh@invalid.ca> wrote:
>>>
>>>> On 2023-08-12, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
 >>>>> On Sat, 12 Aug 2023 18:46:02 -0400, William Unruh
<unruh@invalid.ca> wrote:
>>>>>
>>>>>> And of course just after I sent that out, the systems suddenly started
>>>>>> working again. Not at all clear what happened.
>>>>>
>>>>> Does "ip -s link" show any errors?
>>>>>
>>>>> Regards, Dave Hodgins
>>>>
>>>> On Serv:
>>>>
 >>>> 2: enp4s0:  mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
>>>>     link/ether f8:32:e4:70:14:5b brd ff:ff:ff:ff:ff:ff
>>>>     RX:     bytes   packets errors dropped  missed    mcast
>>>>       69357175201 558088800      0   37942       0 15654970
>>>>     TX:     bytes   packets errors dropped carrier  collsns
>>>>     1395857318948 985313209      0       0       0        0
>>>>
>>>> On Client:
 >>>> 2: enp3s0:  mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
>>>>     link/ether 20:cf:30:90:5c:cb brd ff:ff:ff:ff:ff:ff
>>>>     RX:  bytes packets errors dropped  missed   mcast
>>>>      715899055 1004543      0    1095      88   83900
>>>>     TX:  bytes packets errors dropped carrier collsns
>>>>      379358269  614341      0       0       0       0
>>>>
>>>> I have no idea what time span those results cover, and the mount
>>>> problems occured abot 5 days ago.
>>>
>>> The dropped packet count is very high for that number of packets.
>>>
>>> On my system after 2 days since reboot ...
 >>> 2: eth0:  mtu 1500 qdisc
pfifo_fast state UP mode DEFAULT group default qlen 1000
>>>      link/ether 10:fe:ed:03:8d:b3 brd ff:ff:ff:ff:ff:ff
>>>      RX:   bytes  packets errors dropped  missed   mcast
>>>      12995214891 24029134      0       0       0    7143
>>>      TX:   bytes  packets errors dropped carrier collsns
>>>      12474040445 27377647      0       0       0       0
>>>
 >>> All three of my computers, two of which use ethernet and the
other wireless have
>>> zero dropped packets.
>>>
 >>> The most likely causes of packet cause is one or more bad
ethernet cables, bad
>>> sockets, or just not quite being fully plugged into the socket.
>>>
>> Thanks for the hint. It wou.d be strange if such a cause could reliably
>> result in "directory name does not exist" as the message from the server
>> to the client, while ssh connections between the two seems to be fine.
>
> I`m not sure if that is the cause or not. I haven`t looked into how nfs/nfsd
> and ssh/sshd handle some failed packets. It wouldn`t surprise me if they work
 > differently, causing the problem only for nfs. The server may not
be generating
> that message. It may be coming from the client whenever the mount fails.
>
> I`d try fixing that issue and then see if the problem still occurs.
>
> Regards, Dave Hodgins
--- slrn/1.0.3 (Linux)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх