4:33 p.m.
I'm getting "filesystem not responding" messages from an NFS-mounted
NAS which I suspect is just slow (it spins down its disks when not in
use). I'm using automount and that appears to be related as it never
used to happen with normal mounting. I've changed the 'timeo' parameter
in the /etc/fstab line and run 'mount -a' but the mount parameters for
the filesystem have not changed. I've also restarted anything that
seems relevant from systemd:
systemctl restart storage-Backups.mount
and
systemctl restart proc-fs-nfsd.mount
and
systemctl restart proc-sys-fs-binfmt_misc.automount
to no effect.
How can I get this to work without rebooting?
poc
4:56 p.m.
On 11/30/18 2:33 PM, Patrick O'Callaghan wrote:
I'm getting "filesystem not responding" messages from
an NFS-mounted
NAS which I suspect is just slow (it spins down its disks when not in
use). I'm using automount and that appears to be related as it never
used to happen with normal mounting. I've changed the 'timeo' parameter
in the /etc/fstab line and run 'mount -a' but the mount parameters for
the filesystem have not changed. I've also restarted anything that
seems relevant from systemd:
systemctl restart storage-Backups.mount
and
systemctl restart proc-fs-nfsd.mount
and
systemctl restart proc-sys-fs-binfmt_misc.automount
to no effect.
How can I get this to work without rebooting?
Uhm, you might try "mount -o remount,rw,<otheroptions> /mountpoint" or
you may have to unmount it using "umount" (possibly with the "-f"
flag)
and either manually remount or trigger the automount. From the nfs(5)
man page:
With few exceptions, NFS-specific options are not able to be
modified during a remount. The underlying transport or NFS
version cannot be changed by a remount, for example.
I suspect the timeouts fall into those "NFS-specific" bits. With those
caveats, give it a go.
IIRC, the mount options in /etc/fstab are only used at the time of
mounting. Changes to fstab won't take effect without a remount of some
sort. The best remount is a full umount/mount cycle, but umounting
(without the "-f") will require that there are no open files on that
filesystem. Using the "-f" will forcefully dismount it and that can lead
to some grievous consequences to processes actively using the filesystem
at the time of the dismount. Thou hast been warned!
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Blessed are the peacekeepers...for they shall be shot at -
- from both sides. --A.M. Greeley -
----------------------------------------------------------------------
5:48 p.m.
I have often see cases where servers apparently got mad
at specific systems and started refusing to allow them to mount
(even though there were valid export entries for them).
I have fixed this by restarting nfs on the server side.
5:56 p.m.
On Fri, 2018-11-30 at 22:56 +0000, Rick Stevens wrote:
On 11/30/18 2:33 PM, Patrick O'Callaghan wrote:
> I'm getting "filesystem not responding" messages from an NFS-mounted
> NAS which I suspect is just slow (it spins down its disks when not in
> use). I'm using automount and that appears to be related as it never
> used to happen with normal mounting. I've changed the 'timeo' parameter
> in the /etc/fstab line and run 'mount -a' but the mount parameters for
> the filesystem have not changed. I've also restarted anything that
> seems relevant from systemd:
>
> systemctl restart storage-Backups.mount
> and
> systemctl restart proc-fs-nfsd.mount
> and
> systemctl restart proc-sys-fs-binfmt_misc.automount
>
> to no effect.
>
> How can I get this to work without rebooting?
Uhm, you might try "mount -o remount,rw,<otheroptions> /mountpoint" or
you may have to unmount it using "umount" (possibly with the "-f"
flag)
and either manually remount or trigger the automount.
That did it (using '-f' as you say). Interestingly it wouldn't unmount
otherwise, even though nothing is using it. Presumably systemd
automount is preventing it. When I tried to list a directory on the
system it didn't respond, but doing an ssh to the box spins up the
disks and lets me log in. So I've no idea what exactly automount is
supposed to be doing.
Anyway, it's all good now, thanks.
poc
5:58 p.m.
On Fri, 2018-11-30 at 16:19 -0700, Joe Zeff wrote:
On 11/30/2018 03:33 PM, Patrick O'Callaghan wrote:
> How can I get this to work without rebooting?
Have you tried unmounting it and then remounting it? Not sure why it
would work if mount -a doesn't, but it doesn't take long to make sure.
Yes, that worked. It turns out that 'mount -a' doesn't remount things
that are already mounted. I'm just too used to doing that when messing
with NFS.
poc
6:03 p.m.
On 12/1/18 6:33 AM, Patrick O'Callaghan wrote:
I'm getting "filesystem not responding" messages from
an NFS-mounted
NAS which I suspect is just slow (it spins down its disks when not in
use). I'm using automount and that appears to be related as it never
used to happen with normal mounting. I've changed the 'timeo' parameter
in the /etc/fstab line and run 'mount -a' but the mount parameters for
the filesystem have not changed. I've also restarted anything that
seems relevant from systemd:
systemctl restart storage-Backups.mount
and
systemctl restart proc-fs-nfsd.mount
and
systemctl restart proc-sys-fs-binfmt_misc.automount
to no effect.
How can I get this to work without rebooting?
I know you have it working....
But I did verify that unmounting and remounting with a changed parameter has no effect.
Then, I did umount, systemctl daemon-reload, mount and the changes took effect.
So, that would be a second way.
--
Right: I dislike the default color scheme Wrong: What idiot picked the default color
scheme
3:49 a.m.
On Sat, 2018-12-01 at 08:03 +0800, Ed Greshko wrote:
On 12/1/18 6:33 AM, Patrick O'Callaghan wrote:
> I'm getting "filesystem not responding" messages from an NFS-mounted
> NAS which I suspect is just slow (it spins down its disks when not in
> use). I'm using automount and that appears to be related as it never
> used to happen with normal mounting. I've changed the 'timeo' parameter
> in the /etc/fstab line and run 'mount -a' but the mount parameters for
> the filesystem have not changed. I've also restarted anything that
> seems relevant from systemd:
>
> systemctl restart storage-Backups.mount
> and
> systemctl restart proc-fs-nfsd.mount
> and
> systemctl restart proc-sys-fs-binfmt_misc.automount
>
> to no effect.
>
> How can I get this to work without rebooting?
>
I know you have it working....
But I did verify that unmounting and remounting with a changed parameter has no effect.
Except that it did have an effect. I used 'umount -f ...' and then
'mount -a' and it worked.
Then, I did umount, systemctl daemon-reload, mount and the changes
took effect.
So, that would be a second way.
I hadn't tried the daemon-reload so that might have worked too.
poc
4:04 a.m.
On 12/1/18 5:49 PM, Patrick O'Callaghan wrote:
On Sat, 2018-12-01 at 08:03 +0800, Ed Greshko wrote:
> On 12/1/18 6:33 AM, Patrick O'Callaghan wrote:
>> I'm getting "filesystem not responding" messages from an
NFS-mounted
>> NAS which I suspect is just slow (it spins down its disks when not in
>> use). I'm using automount and that appears to be related as it never
>> used to happen with normal mounting. I've changed the 'timeo'
parameter
>> in the /etc/fstab line and run 'mount -a' but the mount parameters for
>> the filesystem have not changed. I've also restarted anything that
>> seems relevant from systemd:
>>
>> systemctl restart storage-Backups.mount
>> and
>> systemctl restart proc-fs-nfsd.mount
>> and
>> systemctl restart proc-sys-fs-binfmt_misc.automount
>>
>> to no effect.
>>
>> How can I get this to work without rebooting?
>>
> I know you have it working....
>
> But I did verify that unmounting and remounting with a changed parameter has no
effect.
Except that it did have an effect. I used 'umount -f ...' and then
'mount -a' and it worked.
Yes, that is why I said "I know you have it working". :-) :-)
> Then, I did umount, systemctl daemon-reload, mount and the
changes took effect.
>
> So, that would be a second way.
I hadn't tried the daemon-reload so that might have worked too.
It would have worked. I tested it to make sure.
It regenerates the unit files such as these....
syntegra.automount generated
syntegra.mount generated
--
Right: I dislike the default color scheme Wrong: What idiot picked the default color
scheme
5:14 a.m.
On Sat, 2018-12-01 at 18:04 +0800, Ed Greshko wrote:
> > I know you have it working....
> >
> > But I did verify that unmounting and remounting with a changed parameter has no
effect.
> Except that it did have an effect. I used 'umount -f ...' and then
> 'mount -a' and it worked.
Yes, that is why I said "I know you have it working". :-) :-)
But you also said 'I did verify that unmounting and remounting with a
changed parameter has no effect', which is contrary to what I found ;-)
poc
5:18 a.m.
On 12/1/18 7:14 PM, Patrick O'Callaghan wrote:
On Sat, 2018-12-01 at 18:04 +0800, Ed Greshko wrote:
>>> I know you have it working....
>>>
>>> But I did verify that unmounting and remounting with a changed parameter has
no effect.
>> Except that it did have an effect. I used 'umount -f ...' and then
>> 'mount -a' and it worked.
> Yes, that is why I said "I know you have it working". :-) :-)
But you also said 'I did verify that unmounting and remounting with a
changed parameter has no effect', which is contrary to what I found ;-)
No, I didn't use the "-f". So, not contrary, just not clarified. :-)
--
Right: I dislike the default color scheme Wrong: What idiot picked the default color
scheme
5:55 a.m.
On Sat, 2018-12-01 at 19:18 +0800, Ed Greshko wrote:
On 12/1/18 7:14 PM, Patrick O'Callaghan wrote:
> On Sat, 2018-12-01 at 18:04 +0800, Ed Greshko wrote:
> > > > I know you have it working....
> > > >
> > > > But I did verify that unmounting and remounting with a changed
parameter has no effect.
> > > Except that it did have an effect. I used 'umount -f ...' and
then
> > > 'mount -a' and it worked.
> > Yes, that is why I said "I know you have it working". :-) :-)
> But you also said 'I did verify that unmounting and remounting with a
> changed parameter has no effect', which is contrary to what I found ;-)
>
No, I didn't use the "-f". So, not contrary, just not clarified. :-)
Without the '-f' it simply wouldn't unmount for me (it just sat there),
so maybe your setup is different. Either way it's working now so thanks
anyway.
poc
6:15 a.m.
On 12/1/18 7:55 PM, Patrick O'Callaghan wrote:
Without the '-f' it simply wouldn't unmount for me (it
just sat there),
so maybe your setup is different. Either way it's working now so thanks
anyway.
Good.
I have had very little, I'd even say no, problems with NFS. Especially after adding
x-systemd.automount to the fstab entries.
--
Right: I dislike the default color scheme Wrong: What idiot picked the default color
scheme
8:08 a.m.
On Sat, 2018-12-01 at 20:15 +0800, Ed Greshko wrote:
On 12/1/18 7:55 PM, Patrick O'Callaghan wrote:
> Without the '-f' it simply wouldn't unmount for me (it just sat there),
> so maybe your setup is different. Either way it's working now so thanks
> anyway.
Good.
I have had very little, I'd even say no, problems with NFS. Especially after adding
x-systemd.automount to the fstab entries.
That's what I have now. I think my issue may have been due to messing
with that on a live system. I made several changes and I think it got
into a funny state. I've since rebooted and it's all good now (crosses
fingers).
poc
7:50 a.m.
Allegedly, on or about 30 November 2018, Patrick O'Callaghan sent:
When I tried to list a directory on the system it didn't respond,
but
doing an ssh to the box spins up the disks and lets me log in. So
I've no idea what exactly automount is supposed to be doing.
I have a similar issue. If the NAS has gone to sleep, it's very hard
to wake up. It takes so long, that the autofs thing that Fedora does
gives up and refuses to try again. If I open up the webserver
interface to the NAS, rummage around the contents a bit, the drive
wakes up, and then NFS automounts work fine.
Another NAS is quicker at coming to life, and doesn't have that
problem.
If something has got its hooks into trying to use autofs (like a
Nautilus browser window, or an application's file requester), this can
really jam up the works on an automount that's not mounting.
I'd like to know if I can tweak a timeout for autofs, I didn't used to
have this problem.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.16.11-100.fc26.x86_64 #1 SMP Tue May 22 20:02:12 UTC 2018 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
Linux cures Windows pains.
8:16 a.m.
On 12/3/18 9:50 PM, Tim via users wrote:
Allegedly, on or about 30 November 2018, Patrick O'Callaghan
sent:
> When I tried to list a directory on the system it didn't respond, but
> doing an ssh to the box spins up the disks and lets me log in. So
> I've no idea what exactly automount is supposed to be doing.
I have a similar issue. If the NAS has gone to sleep, it's very hard
to wake up. It takes so long, that the autofs thing that Fedora does
gives up and refuses to try again. If I open up the webserver
interface to the NAS, rummage around the contents a bit, the drive
wakes up, and then NFS automounts work fine.
Another NAS is quicker at coming to life, and doesn't have that
problem.
If something has got its hooks into trying to use autofs (like a
Nautilus browser window, or an application's file requester), this can
really jam up the works on an automount that's not mounting.
I'd like to know if I can tweak a timeout for autofs, I didn't used to
have this problem.
Have a look at x-systemd.device-timeout and x-systemd.mount-timeout in "man
systemd.mount".
I've not had problems since my NFS server is pretty darn quick even if the drives
have
spun down. So, I've not had to research this. And, since everything works well for
me,
I've no way to really test.
--
Right: I dislike the default color scheme Wrong: What idiot picked the default color
scheme
11:27 a.m.
On Tue, 2018-12-04 at 00:20 +1030, Tim via users wrote:
Allegedly, on or about 30 November 2018, Patrick O'Callaghan
sent:
> When I tried to list a directory on the system it didn't respond, but
> doing an ssh to the box spins up the disks and lets me log in. So
> I've no idea what exactly automount is supposed to be doing.
I have a similar issue. If the NAS has gone to sleep, it's very hard
to wake up. It takes so long, that the autofs thing that Fedora does
gives up and refuses to try again. If I open up the webserver
interface to the NAS, rummage around the contents a bit, the drive
wakes up, and then NFS automounts work fine.
I think what I was seeing was something else. I probably messed up when
trying various /etc/fstab settings and systemd reloads. I rebooted and
it started working.
poc
11:38 a.m.
On 12/1/18 1:49 AM, Patrick O'Callaghan wrote:
On Sat, 2018-12-01 at 08:03 +0800, Ed Greshko wrote:
> On 12/1/18 6:33 AM, Patrick O'Callaghan wrote:
>> I'm getting "filesystem not responding" messages from an
NFS-mounted
>> NAS which I suspect is just slow (it spins down its disks when not in
>> use). I'm using automount and that appears to be related as it never
>> used to happen with normal mounting. I've changed the 'timeo'
parameter
>> in the /etc/fstab line and run 'mount -a' but the mount parameters for
>> the filesystem have not changed. I've also restarted anything that
>> seems relevant from systemd:
>>
>> systemctl restart storage-Backups.mount
>> and
>> systemctl restart proc-fs-nfsd.mount
>> and
>> systemctl restart proc-sys-fs-binfmt_misc.automount
>>
>> to no effect.
>>
>> How can I get this to work without rebooting?
>>
>
> I know you have it working....
>
> But I did verify that unmounting and remounting with a changed parameter has no
effect.
Except that it did have an effect. I used 'umount -f ...' and then
'mount -a' and it worked.
"mount -a" will only mount things that aren't already mounted. It
worked after the "umount -f" because that forced the unmount first, then
the "mount -a" would remount.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- "More hay, Trigger?" "No thanks, Roy, I'm stuffed!"
-
----------------------------------------------------------------------
12:33 p.m.
On Mon, 2018-12-03 at 17:38 +0000, Rick Stevens wrote:
On 12/1/18 1:49 AM, Patrick O'Callaghan wrote:
> On Sat, 2018-12-01 at 08:03 +0800, Ed Greshko wrote:
> > On 12/1/18 6:33 AM, Patrick O'Callaghan wrote:
> > > I'm getting "filesystem not responding" messages from an
NFS-mounted
> > > NAS which I suspect is just slow (it spins down its disks when not in
> > > use). I'm using automount and that appears to be related as it never
> > > used to happen with normal mounting. I've changed the 'timeo'
parameter
> > > in the /etc/fstab line and run 'mount -a' but the mount parameters
for
> > > the filesystem have not changed. I've also restarted anything that
> > > seems relevant from systemd:
> > >
> > > systemctl restart storage-Backups.mount
> > > and
> > > systemctl restart proc-fs-nfsd.mount
> > > and
> > > systemctl restart proc-sys-fs-binfmt_misc.automount
> > >
> > > to no effect.
> > >
> > > How can I get this to work without rebooting?
> > >
> >
> > I know you have it working....
> >
> > But I did verify that unmounting and remounting with a changed parameter has no
effect.
>
> Except that it did have an effect. I used 'umount -f ...' and then
> 'mount -a' and it worked.
"mount -a" will only mount things that aren't already mounted. It
worked after the "umount -f" because that forced the unmount first, then
the "mount -a" would remount.
Yes, I realise that.
poc
1968
days inactive
1971
days old
18 comments
6 participants
participants (6)
-
Ed Greshko -
Joe Zeff -
Patrick O'Callaghan -
Rick Stevens -
Tim -
Tom Horsley