I’ve updated a PC to 13.1 from 11.X on a machine primarily used to stream media stored on NFS servers.
Other than the ‘upgrade’ the client hasn’t changed.
Once the system rebooted I was required to manually restart the NFS service.
Previous versions enabled the NFS automatically
The NFS client service no longer seems to work sensibly
Am I supposed to start NFS manually after each boot or what?
The instructions on this link worked for me…
On 2014-08-10 22:46, sem101 wrote:
>
> I’ve updated a PC to 13.1 from 11.X on a machine primarily used to
> stream media stored on NFS servers.
> Other than the ‘upgrade’ the client hasn’t changed.
Upgrade, how exactly?
Or did you install 13.1 fresh on the same machine that had 11.X before?
> Once the system rebooted I was required to manually restart the NFS
> service.
> Previous versions enabled the NFS automatically
systemctl status nfs.service
systemctl enable nfs.service
systemctl start nfs.service
systemctl status nfs.service
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
[QUOTE=ionmich;2658631]The instructions on this link worked for me…
Thanks but not quite on topic as it is the NFS client that is no longer working on boot as it did in previous versions.
Yes - actually I replaced the HD with a blank one - so not exactly identical - and then cleanly installed 13.1
Why is the NFS client now broken?
The end result is that 13.1 is a retrograde step in usability for users
The NFS client just fails to run or does not function well at boot and I’d like to resolve that.
Thanks, I have the code info already but I’d like the NFS client to function as unobtrusively as it did previously.
I have other machines to do and it seem I have to script each one in order to cover for this massive functionality fail.
It isn’t.
There’s nothing to fix and there’s no “functionality” fail - the NFS client service functions just as it did before. If you configure it via YAST the services will be configured, started and enabled.
Enabling clients/services automatically is extremely poor behaviour from a security viewpoint.
On 2014-08-11 12:56, sem101 wrote:
> Yes - actually I replaced the HD with a blank one - so not exactly
> identical - and then cleanly installed 13.1
Ok.
> Why is the NFS client now broken?
> The end result is that 13.1 is a retrograde step in usability for users
> The NFS client just fails to run or does not function well at boot and
> I’d like to resolve that.
Did you do what I suggested? What happened then?
NFS is not broken, so calm down.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, NFS is not broken
Your suggestion run fine and NFS client starts up - as it used to do in 11.X - except in 11.X the NFS client would start without manual post-boot input - if that’s not an exemplar of a retrograde step in usability then what is it?
I’m doing exactly as you suggested except I prefer to use clicky/mousy stuff such as runlevel or the partitioner in YAST2 to restart the client manually which I have to do because something has broken how the NFS client sets to work.
Simply put - I am required to restart the NFS client after each boot - I haven’t got the talent or the inclination to rebrand this as a feature or a security protocol just so I may avoid describing it as a usability failure.
And yet the NFS client service is only “configured, started and enabled” after a manual restart - it’s not quite functioning as it did before. Before, I did not have restart the NFS client.
How then would you suggest I get the NFS client to work as intended and as designed
Have you tried configuring via YaST >> System >> Services Manager? (nfs client services). You can also do the same with ‘chkconfig’ if preferred.
On 08/12/2014 09:46 AM, sem101 wrote:
>
> Miuku;2658680 Wrote:
>> It isn’t.
>>
>>
>> There’s nothing to fix and there’s no “functionality” fail - the NFS
>> client service functions just as it did before. If you configure it via
>> YAST the services will be configured, started and enabled.
> And yet the NFS client service is only “configured, started and
> enabled” after a manual restart - it’s not quite functioning as it
> did before. Before, I did not have restart the NFS client.
>
> How then would you suggest I get the NFS client to work as intended and
> as designed
What is the “NFS Client”? There is an RPC service that aids NFS. Is that what
you mean?
I have two 13.1 systems that export NFS volumes. Those were set up with YaST. A
number of systems mount those volumes. For the systems that are always connected
via a wired NIC, the appropriate NFS volumes are mounted at boot. Some of those
mounts were created with YaST, and others by creating the appropriate line in
/etc/fstab. Systems that might use wireless have the info in /etc/fstab, but
with the “noauto” option selected, thus these mounts have to be manually done.
To allow users to mount these volumes, the “users” option is also set.
One thing to note: NFS Version 4 is always disabled on the servers as I have
never gotten it to work.
I cannot reproduce your issue.
I tried on two separate virtual machines with 13.1 updated with normal updates (up to yesterday), with no outside repositories added and after configuring an NFS mount via YAST2 the service was started and enabled to start-up on next boot.
So I don’t know what the problem here is, it functions as intended here. shrug
Thanks, that’s how I manually restart the NFS client in 13.1.
Once the PC has booted into KDE I normally use YaST >> System >> Services Manager to restart NFS so that I can get a functional NFS
Say, are you using NetworkManager or Traditional If-Up?
in 13.1 YaST there is the runlevel ‘module’ giving users an idea of what is running etc.
[by switching to expert mode I can restart a service at a click - which is how I restart the NFS client]
There may well be two NFS services shown; nfs and nfsserver.
I’m not referring to nfsserver because it does not appear to modify or affect the failure experienced here.
I’ve tried adding and removing NFS shares on this machine in order to make nfsserver run at boot as well.
This has had no effect on the client’s failure to function properly at boot.
It is most improbable that you could have replicated this issue in this way… You do not have sufficient information and, probably more importantly, had you been successful then the issue would have been more widespread and might even have been squashed by now - [if it’s not a user issue]
I would certainly be looking at simplifying the install if I was attempting to replicate - if the YaST runlevel ‘module’ is reliable then this machine only has nine services running and I surely bet that you included samba in your virtual install…
I think the start up is too fast [to put it in expert speek]
I think the start up is too fast [to put it in expert speek]
To help progress this, it would be useful to know whether your NFS mounts fail because of network availability at boot, or whether it is simply because the required services are not enabled or failing for some other reason.
After you have booted, but before you have to manually enable the nfs service, what it reported by the following?
systemctl status nfs
systemctl status rpcbind
On 08/12/2014 03:06 PM, sem101 wrote:
>
> lwfinger;2658847 Wrote:
>> What is the “NFS Client”? There is an RPC service that aids NFS. Is that
>> what
>> you mean?
>>
>> I have two 13.1 systems that export NFS volumes. Those were set up with
>> YaST. A
>> number of systems mount those volumes. For the systems that are always
>> connected
>> via a wired NIC, the appropriate NFS volumes are mounted at boot. Some
>> of those
>> mounts were created with YaST, and others by creating the appropriate
>> line in
>> /etc/fstab. Systems that might use wireless have the info in /etc/fstab,
>> but
>> with the “noauto” option selected, thus these mounts have to be manually
>> done.
>> To allow users to mount these volumes, the “users” option is also set.
>
> in 13.1 YaST there is the runlevel ‘module’ giving users an idea of what
> is running etc.
> [by switching to expert mode I can restart a service at a click - which
> is how I restart the NFS client]
> There may well be two NFS services shown; -nfs- and -nfsserver.-
> I’m not referring to -nfsserver- because it does not appear to modify or
> affect the failure experienced here.
> I’ve tried adding and removing NFS shares on this machine in order to
> make -nfsserver- run at boot as well.
> This has had no effect on the client’s failure to function properly at
> boot.
You would need nfsserver if your machine was exporting an NFS volume. For
importing, it is not needed.
On 2014-08-12 16:36, sem101 wrote:
> Your suggestion run fine and NFS client starts up - as it used to do in
> 11.X - except in 11.X the NFS client would start without manual
> post-boot input - if that’s not an exemplar of a retrograde step in
> usability then what is it?
No, if you do what I told you to do (except you failed to post what you
got in the screen here), you should have NFS client working on boot.
Those are the steps to do it.
If it doesn’t work for you (it works for me), then you have some other
issue that has to be investigated.
You will have to give more details about your setup. I’m now going to
read the rest of the thread, and then see if I have further comment to do.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-08-12 23:06, deano ferrari wrote:
>
>> I think the start up is too fast [to put it in expert speek]
> To help progress this, it would be useful to know whether your NFS
> mounts fail because of network availability at boot, or whether it is
> simply because the required services are not enabled or failing for some
> other reason.
We need to know if sem101 is using ifup or network manager, cable
network or wireless. If it is network manager, if it is a user config,
or a global config. And then, whether network manager has been told to
wait for the network to establish or not (there are settings and configs
for that).
I assume there is an entry in fstab for the nfs mount, so please paste
it here.
> After you have booted, but before you have to manually enable the nfs
> service, what it reported by the following?
>
> Code:
> --------------------
> systemctl status nfs
> --------------------
>
>
> Code:
> --------------------
> systemctl status rpcbind
> --------------------
Certainly.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)