On 06/02/2017 04:22, Gordon Messmer wrote:
On Mon, Jan 16, 2017 at 12:36 PM, Stephen Morris
wrote:
My Nas device now fails to mount at boot time via the CIFS definition in
fstab but the corresponding NFS definition mounts quite happily. Also after
the system comes up and I log into KDE I
On Mon, Jan 16, 2017 at 12:36 PM, Stephen Morris
wrote:
> My Nas device now fails to mount at boot time via the CIFS definition in
> fstab but the corresponding NFS definition mounts quite happily. Also after
> the system comes up and I log into KDE I can manually mount the CIFS device.
> As f
On 19/1/17 10:58 pm, Matthew Miller wrote:
On Thu, Jan 19, 2017 at 06:13:11PM +1100, Stephen Morris wrote:
Stephen, are you using NetworkManager?
I am still using NetworkManager, but I am having problems with it at
the moment with it not connecting to my usb wireless device, which
I'm still try
On 19/1/17 8:08 am, Samuel Sieb wrote:
On 01/18/2017 01:39 PM, Stephen Morris wrote:
What I don't understand is when there is a problem why it is always the
CIFS mount that is the one that fails, I would have expected it to be
random as to which one is the one that fails.
Is it possible that th
On Thu, Jan 19, 2017 at 11:06:35AM +, Patrick O'Callaghan wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1119787
> Just as a matter of interest, why does "After=network.target" even
> exist? In what circumstance would this ever be the right thing to do?
It exists for _shutdown_ orderin
On Wed, Jan 18, 2017 at 09:25:31PM -0600, Chris Adams wrote:
> Any service that can be configured to bind to a specific IP should have
> "After=network-online.target" rather than "After=network.target". This
> can be servers for web, mail, FTP, SSH, DNS, logging, and more.
>
> This is a long-stan
On Thu, Jan 19, 2017 at 06:13:11PM +1100, Stephen Morris wrote:
> >Stephen, are you using NetworkManager?
> I am still using NetworkManager, but I am having problems with it at
> the moment with it not connecting to my usb wireless device, which
> I'm still trying to sort out.
Is that the same net
On Wed, 2017-01-18 at 21:25 -0600, Chris Adams wrote:
> Once upon a time, Rick Stevens said:
> > So, it launches
> > the network, says the network is up and moves along even though the
> > network isn't actually up. Your mount is sometimes attempted with a
> > functioning network and sometimes not
On 19/1/17 11:28 am, Matthew Miller wrote:
On Wed, Jan 18, 2017 at 04:37:34PM -0800, Rick Stevens wrote:
I think the issue here is that systemd is non-determinate as to when
things actually get done. systemd simply spawns off some command, flags
itself saying "Ok, that's done" and then goes of
Once upon a time, Rick Stevens said:
> So, it launches
> the network, says the network is up and moves along even though the
> network isn't actually up. Your mount is sometimes attempted with a
> functioning network and sometimes not. You're left to figure out why.
That's not true. systemd dist
On Wed, Jan 18, 2017 at 04:37:34PM -0800, Rick Stevens wrote:
> I think the issue here is that systemd is non-determinate as to when
> things actually get done. systemd simply spawns off some command, flags
> itself saying "Ok, that's done" and then goes off on its merry way. It
> doesn't verify th
On 01/18/2017 02:08 PM, Samuel Sieb wrote:
> On 01/18/2017 01:39 PM, Stephen Morris wrote:
>> What I don't understand is when there is a problem why it is always the
>> CIFS mount that is the one that fails, I would have expected it to be
>> random as to which one is the one that fails.
>>
> Is it
On 01/18/2017 01:39 PM, Stephen Morris wrote:
What I don't understand is when there is a problem why it is always the
CIFS mount that is the one that fails, I would have expected it to be
random as to which one is the one that fails.
Is it possible that the NAS doesn't handle it well when both m
On 19/1/17 6:11 am, Tom Horsley wrote:
On Thu, 19 Jan 2017 07:02:28 +1100
Stephen Morris wrote:
Given
that both the CIFS and NFS mount points are being mounted in parallel it
is now potentially looking like SYSTEMD is problematic in its ability to
handle those mounts in parallel properly.
Nah,
On Thu, 19 Jan 2017 07:02:28 +1100
Stephen Morris wrote:
> Given
> that both the CIFS and NFS mount points are being mounted in parallel it
> is now potentially looking like SYSTEMD is problematic in its ability to
> handle those mounts in parallel properly.
Nah, it isn't parallel mounting, it
On 17/1/17 6:36 am, Stephen Morris wrote:
Hi,
My Nas device now fails to mount at boot time via the CIFS
definition in fstab but the corresponding NFS definition mounts quite
happily. Also after the system comes up and I log into KDE I can
manually mount the CIFS device. As far as I am a
On 18/1/17 7:51 am, Ed Greshko wrote:
On 01/18/17 04:39, Stephen Morris wrote:
Thanks Ed. I haven't written my own systemd units as I haven't investigated how
to do
that, so at the moment I don't have the expertise to do so.
I've written in another response to my original thread that I may hav
On 01/17/2017 12:44 PM, Stephen Morris wrote:
> On 17/1/17 6:36 am, Stephen Morris wrote:
>> Hi,
>>
>> My Nas device now fails to mount at boot time via the CIFS
>> definition in fstab but the corresponding NFS definition mounts quite
>> happily. Also after the system comes up and I log into K
On 01/18/17 05:59, Samuel Sieb wrote:
> On 01/17/2017 01:51 PM, Ed Greshko wrote:
>> OK. As I mentioned, I don't have any mnt-nas.mount unit on my system and I
>> can't find any
>> package in Fedora which would provide that unit. So I just wonder where it
>> comes from.
>>
> systemd automatic
On 01/17/2017 01:51 PM, Ed Greshko wrote:
OK. As I mentioned, I don't have any mnt-nas.mount unit on my system and I
can't find any
package in Fedora which would provide that unit. So I just wonder where it
comes from.
systemd automatically creates temporary units for the entries in the fst
On 01/18/17 04:39, Stephen Morris wrote:
> Thanks Ed. I haven't written my own systemd units as I haven't investigated
> how to do
> that, so at the moment I don't have the expertise to do so.
> I've written in another response to my original thread that I may have found
> what the
> issue is,
On 17/1/17 6:36 am, Stephen Morris wrote:
Hi,
My Nas device now fails to mount at boot time via the CIFS
definition in fstab but the corresponding NFS definition mounts quite
happily. Also after the system comes up and I log into KDE I can
manually mount the CIFS device. As far as I am a
On 17/1/17 7:02 am, fred roller wrote:
On Mon, Jan 16, 2017 at 3:36 PM, Stephen Morris
mailto:samor...@netspace.net.au>> wrote:
Jan 17 06:40:15 localhost.localdomain mount[1299]: mount
error(101): Network is unreachable
At first look it seems the network is not fully up and running
On 17/1/17 9:10 am, Ed Greshko wrote:
On 01/17/17 04:36, Stephen Morris wrote:
Hi,
My Nas device now fails to mount at boot time via the CIFS definition in
fstab but
the corresponding NFS definition mounts quite happily. Also after the system
comes up
and I log into KDE I can manually
On 01/17/17 04:36, Stephen Morris wrote:
> Hi,
>
> My Nas device now fails to mount at boot time via the CIFS definition in
> fstab but
> the corresponding NFS definition mounts quite happily. Also after the system
> comes up
> and I log into KDE I can manually mount the CIFS device. As fa
On Mon, Jan 16, 2017 at 3:36 PM, Stephen Morris
wrote:
> Jan 17 06:40:15 localhost.localdomain mount[1299]: mount error(101):
> Network is unreachable
>
At first look it seems the network is not fully up and running during boot
when the call the mount "/mnt/nas" is made. If you can delay the ca
Hi,
My Nas device now fails to mount at boot time via the CIFS
definition in fstab but the corresponding NFS definition mounts quite
happily. Also after the system comes up and I log into KDE I can
manually mount the CIFS device. As far as I am aware the only difference
between when it w
27 matches
Mail list logo
