4:06 p.m.
Hi,
My Nas Devices are failing to mount at boot time because the
Networkmanager Wait Online Service is failing at boot time. The
following is the output from systemctl that the boot process recommends
being run. Is there anything in that output that would indicate why the
service is failing even though the wifi adapter is indicating that it is
already active before the service fails? This issue happens every time I
boot.
bash-4.4$ systemctl status NetworkManager-wait-online.service
● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded
(/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-10-23 07:38:50
AEDT; 19min ago
Docs: man:nm-online(1)
Process: 1656 ExecStart=/usr/bin/nm-online -s -q --timeout=30
(code=exited, status=1/FAILURE)
Main PID: 1656 (code=exited, status=1/FAILURE)
Oct 23 07:38:20 localhost.localdomain systemd[1]: Starting Network
Manager Wait Online...
Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service: Main process exited, code=exited,
status=1/FAILURE
Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service: Failed with result 'exit-code'.
Oct 23 07:38:50 localhost.localdomain systemd[1]: Failed to start
Network Manager Wait Online.
Regards,
Steve
4:57 p.m.
On 23/10/18 8:06 am, Stephen Morris wrote:
Hi,
My Nas Devices are failing to mount at boot time because the
Networkmanager Wait Online Service is failing at boot time. The
following is the output from systemctl that the boot process
recommends being run. Is there anything in that output that would
indicate why the service is failing even though the wifi adapter is
indicating that it is already active before the service fails? This
issue happens every time I boot.
The other thing I should have mentioned is I also have an ethernet cable
from the pc to a powerline adapter as a failover for the wifi.
regards,
Steve
>
>
> bash-4.4$ systemctl status NetworkManager-wait-online.service
> ● NetworkManager-wait-online.service - Network Manager Wait Online
> Loaded: loaded
> (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled;
> vendor preset: enabled)
> Active: failed (Result: exit-code) since Tue 2018-10-23 07:38:50
> AEDT; 19min ago
> Docs: man:nm-online(1)
> Process: 1656 ExecStart=/usr/bin/nm-online -s -q --timeout=30
> (code=exited, status=1/FAILURE)
> Main PID: 1656 (code=exited, status=1/FAILURE)
>
> Oct 23 07:38:20 localhost.localdomain systemd[1]: Starting Network
> Manager Wait Online...
> Oct 23 07:38:50 localhost.localdomain systemd[1]:
> NetworkManager-wait-online.service: Main process exited, code=exited,
> status=1/FAILURE
> Oct 23 07:38:50 localhost.localdomain systemd[1]:
> NetworkManager-wait-online.service: Failed with result 'exit-code'.
> Oct 23 07:38:50 localhost.localdomain systemd[1]: Failed to start
> Network Manager Wait Online.
>
>
> Regards,
>
> Steve
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:17 p.m.
On 10/23/18 5:57 AM, Stephen Morris wrote:
On 23/10/18 8:06 am, Stephen Morris wrote:
> Hi,
>
> My Nas Devices are failing to mount at boot time because the Networkmanager Wait
> Online Service is failing at boot time. The following is the output from systemctl
that
> the boot process recommends being run. Is there anything in that output that would
> indicate why the service is failing even though the wifi adapter is indicating that
it
> is already active before the service fails? This issue happens every time I boot.
The other thing I should have mentioned is I also have an ethernet cable from the pc to
a powerline adapter as a failover for the wifi.
Have you tried testing with the ethernet cable disconnected at the computer end?
FWIW, I've had spotty success in using the various Networkmanager settings to ensure
my
NAS mounts
succeed at boot time. So, I've changed my fstab add the x-systemd.automount option.
One
of my entries looks
like....
ds6:/volume1/syntegra /syntegra nfs4 rw,soft,fg,x-systemd.automount 0 0
It may, or may not, mount at boot time. But as soon as I access the mount point it will
mount and stay mounted.
>
>
> bash-4.4$ systemctl status NetworkManager-wait-online.service
> ● NetworkManager-wait-online.service - Network Manager Wait Online
> Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service;
enabled;
> vendor preset: enabled)
> Active: failed (Result: exit-code) since Tue 2018-10-23 07:38:50 AEDT; 19min ago
> Docs: man:nm-online(1)
> Process: 1656 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited,
> status=1/FAILURE)
> Main PID: 1656 (code=exited, status=1/FAILURE)
>
> Oct 23 07:38:20 localhost.localdomain systemd[1]: Starting Network Manager Wait
Online...
> Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service:
> Main process exited, code=exited, status=1/FAILURE
> Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service:
> Failed with result 'exit-code'.
> Oct 23 07:38:50 localhost.localdomain systemd[1]: Failed to start Network Manager
Wait
> Online.
>
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
4:25 p.m.
On 23/10/18 9:17 am, Ed Greshko wrote:
On 10/23/18 5:57 AM, Stephen Morris wrote:
> On 23/10/18 8:06 am, Stephen Morris wrote:
>> Hi,
>>
>> My Nas Devices are failing to mount at boot time because the Networkmanager
Wait
>> Online Service is failing at boot time. The following is the output from
systemctl that
>> the boot process recommends being run. Is there anything in that output that
would
>> indicate why the service is failing even though the wifi adapter is indicating
that it
>> is already active before the service fails? This issue happens every time I
boot.
> The other thing I should have mentioned is I also have an ethernet cable from the pc
to
> a powerline adapter as a failover for the wifi.
>
>
Have you tried testing with the ethernet cable disconnected at the computer end?
I
haven't tried this yet, I've been using this setup for over 12 months
and the NetworkManager wait online failure has only just started
occurring in the last couple of weeks.
FWIW, I've had spotty success in using the various Networkmanager settings to ensure
my
NAS mounts
succeed at boot time. So, I've changed my fstab add the x-systemd.automount option.
One
of my entries looks
like....
ds6:/volume1/syntegra /syntegra nfs4 rw,soft,fg,x-systemd.automount 0 0
It may, or may not, mount at boot time. But as soon as I access the mount point it will
mount and stay mounted.
I tried the x-systemd.automount parameter by adding it to the fstab
entry and then trying 'ls /mnt/nfs' which doesn't automount the
partition. Either the change requires a reboot to take effect (I've left
it present to see what happens after next boot, but the same thing also
doesn't work on the cifs mount point either) or it is an nfs4 specific
option, in which case it won't work for me as my nas doesn't support
nfs4 probably for the same reasons as it only supports cifs version 1.
Just for interest below is my fstab specifications for the partition.
The unfortunate thing with the cifs mount point is cifs doesn't support
user mounting.
192.168.0.12:/mnt/HD/HD_a2 /mnt/nfs nfs
users,noatime,nolock,bg,sec=sys,tcp,timeo=1800,_netdev,rw,x-systemd.automount
0 0
//192.168.0.12/Volume_1 /mnt/nas cifs
vers=1.0,username=********,password=********,cache=strict,_netdev,rw,x-systemd.requires=/mnt/nfs
0 0
regards,
Steve
>
>>>
>>> bash-4.4$ systemctl status NetworkManager-wait-online.service
>>> ● NetworkManager-wait-online.service - Network Manager Wait Online
>>> Loaded: loaded
(/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled;
>>> vendor preset: enabled)
>>> Active: failed (Result: exit-code) since Tue 2018-10-23 07:38:50 AEDT;
19min ago
>>> Docs: man:nm-online(1)
>>> Process: 1656 ExecStart=/usr/bin/nm-online -s -q --timeout=30
(code=exited,
>>> status=1/FAILURE)
>>> Main PID: 1656 (code=exited, status=1/FAILURE)
>>>
>>> Oct 23 07:38:20 localhost.localdomain systemd[1]: Starting Network Manager
Wait Online...
>>> Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service:
>>> Main process exited, code=exited, status=1/FAILURE
>>> Oct 23 07:38:50 localhost.localdomain systemd[1]:
NetworkManager-wait-online.service:
>>> Failed with result 'exit-code'.
>>> Oct 23 07:38:50 localhost.localdomain systemd[1]: Failed to start Network
Manager Wait
>>> Online.
>>>
>
4:54 p.m.
On 10/25/18 5:25 AM, Stephen Morris wrote:
I tried the x-systemd.automount parameter by adding it to the fstab
entry and then
trying 'ls /mnt/nfs' which doesn't automount the partition. Either the change
requires a
reboot to take effect (I've left it present to see what happens after next boot, but
the
same thing also doesn't work on the cifs mount point either) or it is an nfs4
specific
option, in which case it won't work for me as my nas doesn't support nfs4
probably for
the same reasons as it only supports cifs version 1. Just for interest below is my fstab
specifications for the partition. The unfortunate thing with the cifs mount point is
cifs doesn't support user mounting.
192.168.0.12:/mnt/HD/HD_a2 /mnt/nfs nfs
users,noatime,nolock,bg,sec=sys,tcp,timeo=1800,_netdev,rw,x-systemd.automount 0 0
//192.168.0.12/Volume_1 /mnt/nas cifs
vers=1.0,username=********,password=********,cache=strict,_netdev,rw,x-systemd.requires=/mnt/nfs
0 0
I do not know the purpose of some of the options you've specified in your fstab. It
may
be that one of them is in conflict
with x-systemd.automount. I suspect the _netdev is responsible for the conflict.
See, https://wiki.archlinux.org/index.php/NFS were it is pointed out....
"Another method is using the systemd automount service. This is a better option than
_netdev, because it remounts the network device quickly when the connection is broken and
restored. As well, it solves the problem from autofs, see the example below:"
That option isn't "nfs4" specific as it has more to do with systemd than the
type of mount.
If you google these terms
x-systemd.automount nfs
x-systemd.automount cifs
You'll find examples of usage.
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
1:46 a.m.
On 25/10/18 8:54 am, Ed Greshko wrote:
On 10/25/18 5:25 AM, Stephen Morris wrote:
> I tried the x-systemd.automount parameter by adding it to the fstab entry and then
> trying 'ls /mnt/nfs' which doesn't automount the partition. Either the
change requires a
> reboot to take effect (I've left it present to see what happens after next boot,
but the
> same thing also doesn't work on the cifs mount point either) or it is an nfs4
specific
> option, in which case it won't work for me as my nas doesn't support nfs4
probably for
> the same reasons as it only supports cifs version 1. Just for interest below is my
fstab
> specifications for the partition. The unfortunate thing with the cifs mount point is
> cifs doesn't support user mounting.
>
>
> 192.168.0.12:/mnt/HD/HD_a2 /mnt/nfs nfs
> users,noatime,nolock,bg,sec=sys,tcp,timeo=1800,_netdev,rw,x-systemd.automount 0 0
> //192.168.0.12/Volume_1 /mnt/nas cifs
>
vers=1.0,username=********,password=********,cache=strict,_netdev,rw,x-systemd.requires=/mnt/nfs
> 0 0
I do not know the purpose of some of the options you've specified in your fstab. It
may
be that one of them is in conflict
with x-systemd.automount. I suspect the _netdev is responsible for the conflict.
Quite some time ago I had issues with the mounts of the network drive
failing at boot time because they were timing out, which adding _netdev,
as suggested by a person on this list who responded to my thread, rectified.
I've added the x-systemd.requires parameter to the cifs mount statement
as some time ago I had issues with the two mount processes interfering
with each other at boot time because systemd was running the two
processes in parallel and the nas device couldn't handle it (The systemd
parameter here was suggested by someone on this list as well). I'm
probably not surprised at the device not being able to handle the two
mount processes on the same physical partition on the device.
See, https://wiki.archlinux.org/index.php/NFS were it is pointed out....
"Another method is using the systemd automount service. This is a better option
than
_netdev, because it remounts the network device quickly when the connection is broken
and
restored. As well, it solves the problem from autofs, see the example below:"
That option isn't "nfs4" specific as it has more to do with systemd than
the type of mount.
I thought it might have been an nfs4 specific command because when I
added it to the mount lines in fstab it did nothing. It turns out you
have to reboot afterwards for it to take effect.
My main concern with this is not the mounts failing at boot, I can
understand why they failed, but more why the networkmanager wait online
process is failing. I tried a boot with the ethernet cable disconnected
from the pc, but that made no difference.
Could vpn definitions be impacting the process? I have a number of vpn
definitions, which are not getting started as I require, but all of them
have the option 'Automatically connect to this network when it is
available' ticked, and both networmanager and 'kde
settings->network->connections' do not let me switch it off.
regards,
Steve
>
> If you google these terms
>
> x-systemd.automount nfs
> x-systemd.automount cifs
>
> You'll find examples of usage.
>
2:15 a.m.
On 10/27/18 2:46 PM, Stephen Morris wrote:
My main concern with this is not the mounts failing at boot, I can
understand why they
failed, but more why the networkmanager wait online process is failing. I tried a boot
with the ethernet cable disconnected from the pc, but that made no difference.
Could vpn definitions be impacting the process? I have a number of vpn definitions,
which are not getting started as I require, but all of them have the option
'Automatically connect to this network when it is available' ticked, and both
networmanager and 'kde
settings->network->connections' do not let me switch it off.
Oh, if you're wanting to mounts to work properly at boot time with only
NetworkManager
WaitOline then I, for one, am unable to offer any help.
I don't have any complicated network setup and no matter what I tried the NFS mounts
didn't consistently work no matter what I tried. So, that is why I went the rc.local
route at first and then switched to auto-fs mounts.
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
4:17 p.m.
On 27/10/18 6:15 pm, Ed Greshko wrote:
On 10/27/18 2:46 PM, Stephen Morris wrote:
> My main concern with this is not the mounts failing at boot, I can understand why
they
> failed, but more why the networkmanager wait online process is failing. I tried a
boot
> with the ethernet cable disconnected from the pc, but that made no difference.
>
> Could vpn definitions be impacting the process? I have a number of vpn definitions,
> which are not getting started as I require, but all of them have the option
> 'Automatically connect to this network when it is available' ticked, and
both
> networmanager and 'kde
settings->network->connections' do not let me switch it off.
Oh, if you're wanting to mounts to work properly at boot time with only
NetworkManager
WaitOline then I, for one, am unable to offer any help.
I don't have any complicated network setup and no matter what I tried the NFS mounts
didn't consistently work no matter what I tried. So, that is why I went the
rc.local
route at first and then switched to auto-fs mounts.
No problems, thankyou for your help Ed.
regards,
Steve
>
4:02 p.m.
On 27/10/18 6:15 pm, Ed Greshko wrote:
On 10/27/18 2:46 PM, Stephen Morris wrote:
> My main concern with this is not the mounts failing at boot, I can understand why
they
> failed, but more why the networkmanager wait online process is failing. I tried a
boot
> with the ethernet cable disconnected from the pc, but that made no difference.
>
> Could vpn definitions be impacting the process? I have a number of vpn definitions,
> which are not getting started as I require, but all of them have the option
> 'Automatically connect to this network when it is available' ticked, and
both
> networmanager and 'kde
settings->network->connections' do not let me switch it off.
Oh, if you're wanting to mounts to work properly at boot time with only
NetworkManager
WaitOline then I, for one, am unable to offer any help.
I don't have any complicated network setup and no matter what I tried the NFS mounts
didn't consistently work no matter what I tried. So, that is why I went the
rc.local
route at first and then switched to auto-fs mounts.
Sorry Ed, just one more question around this. You mentioned in an
earlier thread that you had the auto-mount process working on a CIFS
partition. How did you get it to work, I can't get it to. Both 'LS
/MNT/NAS' and 'SUDO LS /MNT/NAS' fail to mount the partition. I don't
understand why the second command didn't work, as with CIFS only
supporting mounting by Root, the sudo function should have worked.
regards,
Steve
>
>
>
5:57 p.m.
On 10/30/18 5:02 AM, Stephen Morris wrote:
Sorry Ed, just one more question around this. You mentioned in an
earlier thread that
you had the auto-mount process working on a CIFS partition. How did you get it to work,
I can't get it to. Both 'LS /MNT/NAS' and 'SUDO LS /MNT/NAS' fail to
mount the
partition. I don't understand why the second command didn't work, as with CIFS
only
supporting mounting by Root, the sudo function should have worked.
I don't think I said I used cifs mounts. If I implied it, sorry. I've not used
that sort
of mount in a long time.
My NAS, linux based, supports cifs mounts and I just added....
//192.168.1.152/music /mnt cifs username=*****,password=*****,rw,uid=****,gid=**** 0 0
And it does mount at boot and is readable/writeable by the user.
This test may not be valid in your environment. What O/S is running on the server side?
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
9:14 p.m.
On 10/30/18 6:57 AM, Ed Greshko wrote:
This test may not be valid in your environment. What O/S is running
on the server side?
FWIW, I have a Windows 10 VM that I've resurrected. I shared a folder and used the
same
format entry in the fstab.
It mounts just fine on reboot. Having a bit of trouble figuring on the Windows side
allowing writing but that is due to my limited knowledge of MS products and terminology.
:-)
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
4:36 p.m.
On 30/10/18 1:14 pm, Ed Greshko wrote:
On 10/30/18 6:57 AM, Ed Greshko wrote:
> This test may not be valid in your environment. What O/S is running on the server
side?
FWIW, I have a Windows 10 VM that I've resurrected. I shared a folder and used the
same
format entry in the fstab.
It mounts just fine on reboot. Having a bit of trouble figuring on the Windows side
allowing writing but that is due to my limited knowledge of MS products and terminology.
:-)
To be honest I don't know what operating is on the NAS device, and I
can't see any information in the web interface to tell me, but having
said that I haven't really tried to find out either. I'm assuming its
linux, but I can't be sure.
The device seems to show itself as a Windows accessible device by
default (which under Linux I'm using CIFS to mount it) and also provides
an NFS server interface that can be activated if desired (which I have
done and I mount it via NFS under Linux as well). In my fstab entry for
the CIFS mount I've added a systemd parameter to serialise the CIFS
mount behind the nfs mount, as some time ago I had issues where the NAS
controller couldn't handle systemd trying to do the automounting of the
NFS and CIFS mount points at the same time. Both mount points are the
same physical storage, as I can write data to the device under linux via
the CIFS mount point or under Windows 10 and the NFS mount point under
Linux can see the data, but the same doesn't always apply the other way
around. I have a situation where I wrote a .apk file to the device from
linux via the NFS mount point and that file is not visible on the device
from Windows 10 nor from the CIFS mount point under Linux, but as
expected it continues to be visible via the Linux NFS mount point.
With the NFS mount process failing at boot time because of the
Networkmanager Wait Online process timing out, the CIFS serialisation
cause that mount to fail at boot as well, consequently I've added the
x-systemd.automount parameter to both mount definitions in fstab. Having
done this issue the command "ls /mnt/nfs" mounts the nfs interface as
expected, but I can't get the same functionality to mount the CIFS mount
point, which I thought might have something to do with CIFS only being
mountable by root and not by an ordinary user.
regards,
Steve
5:32 p.m.
On 10/31/18 5:36 AM, Stephen Morris wrote:
On 30/10/18 1:14 pm, Ed Greshko wrote:
> On 10/30/18 6:57 AM, Ed Greshko wrote:
>> This test may not be valid in your environment. What O/S is running on the
server side?
> FWIW, I have a Windows 10 VM that I've resurrected. I shared a folder and used
the same
> format entry in the fstab.
>
> It mounts just fine on reboot. Having a bit of trouble figuring on the Windows
side
> allowing writing but that is due to my limited knowledge of MS products and
> terminology. :-)
To be honest I don't know what operating is on the NAS device, and I can't see
any
information in the web interface to tell me, but having said that I haven't really
tried
to find out either. I'm assuming its linux, but I can't be sure.
The device seems to show itself as a Windows accessible device by default (which under
Linux I'm using CIFS to mount it) and also provides an NFS server interface that can
be
activated if desired (which I have done and I mount it via NFS under Linux as well). In
my fstab entry for the CIFS mount I've added a systemd parameter to serialise the
CIFS
mount behind the nfs mount, as some time ago I had issues where the NAS controller
couldn't handle systemd trying to do the automounting of the NFS and CIFS mount
points
at the same time. Both mount points are the same physical storage, as I can write data
to the device under linux via the CIFS mount point or under Windows 10 and the NFS mount
point under Linux can see the data, but the same doesn't always apply the other way
around. I have a situation where I wrote a .apk file to the device from linux via the
NFS mount point and that file is not visible on the device from Windows 10 nor from the
CIFS mount point under Linux, but as expected it continues to be visible via the Linux
NFS mount point.
With the NFS mount process failing at boot time because of the Networkmanager Wait
Online process timing out, the CIFS serialisation cause that mount to fail at boot as
well, consequently I've added the x-systemd.automount parameter to both mount
definitions in fstab. Having done this issue the command "ls /mnt/nfs" mounts
the nfs
interface as expected, but I can't get the same functionality to mount the CIFS
mount
point, which I thought might have something to do with CIFS only being mountable by root
and not by an ordinary user.
Ahhh.... FWIW, I changed my fstab to....
//192.168.1.152/music /music cifs
credentials=/home/egreshko/.cifspw,rw,uid=egreshko,gid=egreshko,x-systemd.automount 0 0
//192.168.1.124/egreshko /home/egreshko/win10 cifs
credentials=/home/egreshko/.cifspw,rw,uid=egreshko,gid=egreshko,x-systemd.automount 0 0
.152 is a Linux based NAS
.124 is a Win10 system
After reboot.....
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648616 19955980 28% /
/dev/sda1 999320 216812 713696 24% /boot
[egreshko@f29bk ~]$ ls /music
ACDC part-1
Adele part-2
'Bruce Springsteen' 'Spyro Gyra - Down The Wire (2009)'
'Lady Gaga' 'The Rolling Stones - GRRR! - Deluxe Edition {mp3
320kbps}'
'Manhattan Transfer'
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648612 19955984 28% /
/dev/sda1 999320 216812 713696 24% /boot
//192.168.1.152/music 2879621632 906374608 1973247024 32% /music
[egreshko@f29bk ~]$ ls win10
'3D Objects'
AppData
<other junk>
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648612 19955984 28% /
/dev/sda1 999320 216812 713696 24% /boot
//192.168.1.152/music 2879621632 906374608 1973247024 32% /music
//192.168.1.124/egreshko 66110996 24305564 41805432 37% /home/egreshko/win10
So, no problems. No root needed.
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
3:55 p.m.
On 31/10/18 9:32 am, Ed Greshko wrote:
On 10/31/18 5:36 AM, Stephen Morris wrote:
> On 30/10/18 1:14 pm, Ed Greshko wrote:
>> On 10/30/18 6:57 AM, Ed Greshko wrote:
>>> This test may not be valid in your environment. What O/S is running on the
server side?
>> FWIW, I have a Windows 10 VM that I've resurrected. I shared a folder and
used the same
>> format entry in the fstab.
>>
>> It mounts just fine on reboot. Having a bit of trouble figuring on the Windows
side
>> allowing writing but that is due to my limited knowledge of MS products and
>> terminology. :-)
> To be honest I don't know what operating is on the NAS device, and I can't
see any
> information in the web interface to tell me, but having said that I haven't
really tried
> to find out either. I'm assuming its linux, but I can't be sure.
>
> The device seems to show itself as a Windows accessible device by default (which
under
> Linux I'm using CIFS to mount it) and also provides an NFS server interface that
can be
> activated if desired (which I have done and I mount it via NFS under Linux as well).
In
> my fstab entry for the CIFS mount I've added a systemd parameter to serialise the
CIFS
> mount behind the nfs mount, as some time ago I had issues where the NAS controller
> couldn't handle systemd trying to do the automounting of the NFS and CIFS mount
points
> at the same time. Both mount points are the same physical storage, as I can write
data
> to the device under linux via the CIFS mount point or under Windows 10 and the NFS
mount
> point under Linux can see the data, but the same doesn't always apply the other
way
> around. I have a situation where I wrote a .apk file to the device from linux via
the
> NFS mount point and that file is not visible on the device from Windows 10 nor from
the
> CIFS mount point under Linux, but as expected it continues to be visible via the
Linux
> NFS mount point.
>
> With the NFS mount process failing at boot time because of the Networkmanager Wait
> Online process timing out, the CIFS serialisation cause that mount to fail at boot
as
> well, consequently I've added the x-systemd.automount parameter to both mount
> definitions in fstab. Having done this issue the command "ls /mnt/nfs"
mounts the nfs
> interface as expected, but I can't get the same functionality to mount the CIFS
mount
> point, which I thought might have something to do with CIFS only being mountable by
root
> and not by an ordinary user.
>
>
Ahhh.... FWIW, I changed my fstab to....
//192.168.1.152/music /music cifs
credentials=/home/egreshko/.cifspw,rw,uid=egreshko,gid=egreshko,x-systemd.automount 0 0
//192.168.1.124/egreshko /home/egreshko/win10 cifs
credentials=/home/egreshko/.cifspw,rw,uid=egreshko,gid=egreshko,x-systemd.automount 0 0
.152 is a Linux based NAS
.124 is a Win10 system
After reboot.....
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648616 19955980 28% /
/dev/sda1 999320 216812 713696 24% /boot
[egreshko@f29bk ~]$ ls /music
ACDC part-1
Adele part-2
'Bruce Springsteen' 'Spyro Gyra - Down The Wire (2009)'
'Lady Gaga' 'The Rolling Stones - GRRR! - Deluxe Edition {mp3
320kbps}'
'Manhattan Transfer'
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648612 19955984 28% /
/dev/sda1 999320 216812 713696 24% /boot
//192.168.1.152/music 2879621632 906374608 1973247024 32% /music
[egreshko@f29bk ~]$ ls win10
'3D Objects'
AppData
<other junk>
[egreshko@f29bk ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_f29bk-root 29106188 7648612 19955984 28% /
/dev/sda1 999320 216812 713696 24% /boot
//192.168.1.152/music 2879621632 906374608 1973247024 32% /music
//192.168.1.124/egreshko 66110996 24305564 41805432 37% /home/egreshko/win10
So, no problems. No root needed.
When I issue df I get :
bash-4.4$ df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 8177492 0 8177492 0% /dev
tmpfs 8190472 484 8189988 1% /dev/shm
tmpfs 8190472 1748 8188724 1% /run
tmpfs 8190472 0 8190472 0% /sys/fs/cgroup
/dev/sdc6 847903444 65097840 739711488 9% /
tmpfs 8190472 56 8190416 1% /tmp
/dev/sda1 358396 51648 306748 15% /mnt/win-sys
/dev/sda6 9946988 170272 9248384 2% /mnt/ubuntu_boot
/dev/sda5 9946988 292968 9125688 4% /boot
/dev/sda2 228758524 114954456 113804068 51% /mnt/windows
/dev/sdc9 847902420 9159932 795648424 2% /mnt/ubuntu_root
/dev/sdc5 103181592 7231276 90685932 8% /home
/dev/sdc8 103181592 2062740 95854468 3% /mnt/ubuntu_home
/dev/sdb1 1953513468 1015969732 937543736 53% /mnt/win_data
tmpfs 1638092 12 1638080 1% /run/user/1000
My fstab CIFS entry is:
//192.168.0.12/Volume_1 /mnt/nas cifs
vers=1.0,username=*,password=*,cache=strict,rw,x-systemd.requires=/mnt/nfs,x-systemd.automount
0 0
If I issue the mount command as myself I get the following:
bash-4.4$ mount /mnt/nas
mount: /mnt/nas: operation permitted for root only.
If I add the users parameter to the fstab entry mount then tells me CIFS
doesn't allow user mounts.
//192.168.0.12/Volume_1 /mnt/nas cifs
vers=1.0,users,username=*,password=*,cache=strict,rw,x-systemd.requires=/mnt/nfs,x-systemd.automount
0 0
bash-4.4$ mount /mnt/nas
This program is not installed setuid root - "user" CIFS mounts not
supported.
Listing the contents of /mnt/nas produces the following:
bash-4.4$ ls /mnt/nas
bash-4.4$ df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 8177492 0 8177492 0% /dev
tmpfs 8190472 532 8189940 1% /dev/shm
tmpfs 8190472 1748 8188724 1% /run
tmpfs 8190472 0 8190472 0% /sys/fs/cgroup
/dev/sdc6 847903444 65097844 739711484 9% /
tmpfs 8190472 56 8190416 1% /tmp
/dev/sda1 358396 51648 306748 15% /mnt/win-sys
/dev/sda6 9946988 170272 9248384 2% /mnt/ubuntu_boot
/dev/sda5 9946988 292968 9125688 4% /boot
/dev/sda2 228758524 114954456 113804068 51% /mnt/windows
/dev/sdc9 847902420 9159932 795648424 2% /mnt/ubuntu_root
/dev/sdc5 103181592 7231708 90685500 8% /home
/dev/sdc8 103181592 2062740 95854468 3% /mnt/ubuntu_home
/dev/sdb1 1953513468 1015969732 937543736 53% /mnt/win_data
tmpfs 1638092 12 1638080 1% /run/user/1000
Have I done something wrong in my setup? I can't remove the
x-systemd.requires parameter unless there is some way of stopped systemd
from trying to mount the nfs and cifs mount points at the same time,
because with my device they interfere with each other and eventually
time out result in them not being mounted anyway.
regards,
Steve
>
4:34 p.m.
On 1/11/18 8:07 am, Ed Greshko wrote:
On 11/1/18 4:55 AM, Stephen Morris wrote:
> bash-4.4$ mount /mnt/nas
Why are you using "mount"?
Just doing an ls or changing into the dir will *auto* mount. That's the whole idea.
I was issuing the mount command to show what happens in my case to see
if there was any information there, along with my fstab entry, to
indicate why issuing the ls command doesn't *auto* mount. Also a cd into
/mnt/nas doesn't *auto* mount either.
regards,
Steve
4:44 p.m.
On 1/11/18 8:34 am, Stephen Morris wrote:
On 1/11/18 8:07 am, Ed Greshko wrote:
> On 11/1/18 4:55 AM, Stephen Morris wrote:
>> bash-4.4$ mount /mnt/nas
> Why are you using "mount"?
>
> Just doing an ls or changing into the dir will *auto* mount. That's
> the whole idea.
>
I was issuing the mount command to show what happens in my case to see
if there was any information there, along with my fstab entry, to
indicate why issuing the ls command doesn't *auto* mount. Also a cd
into /mnt/nas doesn't *auto* mount either.
I removed the x-systemd.requires parameter as a test and issuing a ls
/mnt/nas *auto* mounts the mount point. Why x-systemd.requires=/mnt/nfs
interferes with x-systemd.automount, even when /mnt/nfs has already been
*auto* mounted, I don't know.
Thankyou for your assistance Ed.
regards,
Steve
>
>
> regards,
>
> Steve
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:38 p.m.
On 11/1/18 5:44 AM, Stephen Morris wrote:
I removed the x-systemd.requires parameter as a test and issuing a ls
/mnt/nas *auto*
mounts the mount point. Why x-systemd.requires=/mnt/nfs interferes with
x-systemd.automount, even when /mnt/nfs has already been
*auto* mounted, I don't know.
Thankyou for your assistance Ed.
Glad it is working now.
--
Fedora Users - The place to go to beat OT dead horses :-) :-)
5:47 p.m.
On 11/1/18 6:38 AM, Ed Greshko wrote:
On 11/1/18 5:44 AM, Stephen Morris wrote:
> I removed the x-systemd.requires parameter as a test and issuing a ls /mnt/nas
*auto*
> mounts the mount point. Why x-systemd.requires=/mnt/nfs interferes with
> x-systemd.automount, even when /mnt/nfs has already been
*auto* mounted, I don't know.
>
> Thankyou for your assistance Ed.
Glad it is working now.
Oh, for future reference, when searching for a solution to a problem it seems to work out
best (for me) following these steps.
1. If a "solution" is provided by someone, and it is shown to work, duplicate
that
solution *exactly*.
2. If that provided solution then works as expect add any "local" configuration
which you
think you may need.
3. If adding additional configuration parameters breaks the solution then rethink why
you
thought you needed it in the first place.
--
Fedora Users - The place to go to beat OT dead horses :-) :-)
8:05 p.m.
FWIW....
As I mentioned earlier, my fstab contains
ds6:/volume1/syntegra /syntegra nfs4 rw,soft,bg,x-systemd.automount 0 0
The ping time between the client and server is about 288 ms.
After reboot when I first connect to the client system...
[egreshko@acer ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_acer-root 51343840 15752124 32953892 33% /
/dev/sda1 999320 206740 723768 23% /boot
/dev/mapper/fedora_acer-home 208563940 1883836 196015964 1% /home
Then
[egreshko@acer ~]$ time ls /syntegra
backups linux-releases Vmware
real 0m9.494s
user 0m0.000s
sys 0m0.007s
[egreshko@acer ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora_acer-root 51343840 15752120 32953896 33% /
/dev/sda1 999320 206740 723768 23% /boot
/dev/mapper/fedora_acer-home 208563940 1883836 196015964 1% /home
ds6:/volume1/syntegra 2879621632 905944832 1973574400 32% /syntegra
And from then on....
[egreshko@acer ~]$ time ls /syntegra
backups linux-releases Vmware
real 0m0.582s
user 0m0.002s
sys 0m0.004s
5:44 p.m.
On Tue, 23 Oct 2018 08:06:28 +1100
Stephen Morris wrote:
My Nas Devices are failing to mount at boot time
I've never see any indication that the wait online
service works to achieve anything remotely useful.
There have been threads in this list with huge
long analysis of exactly what isn't working and
why, but I just move a lot of network related stuff
to rc.local with delays and it works much more reliably.
My /etc/rc.d/rc.local file now looks like:
#!/bin/sh
#
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/etc/rc.d/the-real-rc.local
HERE
That solves a recent problem with systemd completely
screwing up rc.local by trying to wait on everything
it might start in the background. I move all my rc.local
processing to a separate thread of control where
systemd can't find it and screw it up.
Then in my /etc/rc.d/the-real-rc.local file, I can
put stuff like this:
#!/bin/sh
/bin/bash -c 'sleep 20 ; mount -t nfs -a' > /dev/null 2>&1 <
/dev/null &
Much more reliable.
4:42 p.m.
On 23/10/18 9:44 am, Tom Horsley wrote:
On Tue, 23 Oct 2018 08:06:28 +1100
Stephen Morris wrote:
> My Nas Devices are failing to mount at boot time
I've never see any indication that the wait online
service works to achieve anything remotely useful.
There have been threads in this list with huge
long analysis of exactly what isn't working and
why, but I just move a lot of network related stuff
to rc.local with delays and it works much more reliably.
My /etc/rc.d/rc.local file now looks like:
#!/bin/sh
#
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/etc/rc.d/the-real-rc.local
HERE
That solves a recent problem with systemd completely
screwing up rc.local by trying to wait on everything
it might start in the background. I move all my rc.local
processing to a separate thread of control where
systemd can't find it and screw it up.
Then in my /etc/rc.d/the-real-rc.local file, I can
put stuff like this:
#!/bin/sh
/bin/bash -c 'sleep 20 ; mount -t nfs -a' > /dev/null 2>&1 <
/dev/null &
Much more reliable.
I may or may not be having the rc.local issue as I don't appear to have
one. If I issue a 'la /etc/rc.d I get the following output:
. .. init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d
'ls /etc/rc.d/init.d then gives the following:
ecbd functions jexec livesys livesys-late netconsole network README
'ls /etc/rc.d/rc0.d gives the following:
K01livesys-late K05jexec K50netconsole K89ecbd K90network K99livesys
'ls /etc/rc.d/rc3.d gives the following:
K50netconsole S00livesys S10network S11ecbd S95jexec S99livesys-late
regards,
Steve
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
4:58 p.m.
On 10/25/18 5:42 AM, Stephen Morris wrote:
I may or may not be having the rc.local issue as I don't appear
to have one.
You have to create it yourself.
See....
/lib/systemd/system/rc-local.service for details.
FWIW, I used to use the method described by Tom but found it a pain to implement every
time I created a VM.
The x-systemd.automount even works well on systems which are 10,000 miles apart. :-)
--
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them,
then tell them what you told them."
1:49 a.m.
On 25/10/18 8:58 am, Ed Greshko wrote:
On 10/25/18 5:42 AM, Stephen Morris wrote:
> I may or may not be having the rc.local issue as I don't appear to have one.
You have to create it yourself.
I realised after I sent the email that might be the case, and then
cursed myself for being so stupid.
regards,
Steve
>
> See....
>
> /lib/systemd/system/rc-local.service for details.
>
> FWIW, I used to use the method described by Tom but found it a pain to implement
every
> time I created a VM.
>
> The x-systemd.automount even works well on systems which are 10,000 miles apart.
:-)
>
2051
days inactive
2060
days old
23 comments
3 participants
participants (3)
-
Ed Greshko -
Stephen Morris -
Tom Horsley