let me just say that you’re wasting your time chasing problems that may well be fixed by updated packets. It’s not about kernel versions, but NFS client packets - the TID indicated there had been important changes in that area, so not updating means keeping old problems.
I do not understand why linux140 uses /usr/lib/systemd/system/nfs and linux283 uses /etc/init.d/nfs. An interesting difference where I would not have expected it.
Most likely because of you not having the latest updates on linux283.
On linux283 before the nfsservice starts the error is a bad mount option but does not provide the bad mount option.
Most likely there is no bad mount option - the mount options provided probably lead to an error during setup, which likely is indistinguishable from bad options at the upper layers.
Why is there this drastic change with Suse 12 on slightly different kernel levels?
You’re the only one talking about kernels
I would have expected these nfs services to both use systemd!
Both do. One system is using the LSB wrapper, the other one dedicated units. Most likely due to updates to the NFS client, ans mentioned in the TID. There usually are reasons for updates.
Can linux283 be changed to use /usr/lib/systemd/system/nfs?
Ask again once you’ve updated to the latest patches
What configuration file is used by *
Both are text files, go check it out - or open a service request, if you want SUSE to respond. We’re volunteers here, this is a peer-to-peer support forum…
PS: “I have not looked at the server side because the issue appears to originate from the client side.”: As has been indicated both by the client-side error message, it could be some reaction of the server to the client request, leading to an according server response. Refusing to check the server’s messages for indications doesn’t sound … logical.