[SOLVED] NFS-mounted $HOME directories does not work on local graphical login, but works on ssh/tty

someshpr · 08-19-2017, 08:12 AM

Quote:

Originally Posted by IsaacKuo

This might indicate that there's something messed up with the nfs file server. I'm not sure how to troubleshoot this.

There is some risk with the "nolock" option if more than one client accesses the same file at the same time. This actually isn't a huge problem for a lot of software, such as vi, which create a small utility file when someone is editing a file (instead of holding a file lock for minutes/hours ... not recommended!). But if, say, two people have software appending stuff to a shared log file on two different computers, there's a good chance a log entry will get overwritten due to two simultaneous log appends at some point.

...

So, even though I'm not really sure how to troubleshoot your nfs server for the "nolock" problem, I suggest you look around for how to try and figure it out.

I agree with IsaacKuo, something is not right with the NFS file server. And this can cause potential data corruption. I'll have to figure out what is wrong with NFS server eventually, but at least my users can login now!

I'll probably experiment with the NFS options separately to figure out the issue with "nolock" option, and may be start a new thread when I get stuck and when I have more pertinent information.

Thanks again,

MadeInGermany · 08-19-2017, 01:12 PM

Do you have NFSv3?

Code:

mount
nfsstat -m

tell vers=X
In NFSv3 there is a separate NLM protocol with lockd running on both NFS client and server. Also statd should run on both (restores locks after a system boot).

Not running NFS locking runs surprisingly well.
Bash and tcsh lock their history files - absolute unnecessary!

someshpr · 08-20-2017, 07:44 AM

Quote:

Originally Posted by MadeInGermany

Do you have NFSv3?

Code:

mount
nfsstat -m

tell vers=X
In NFSv3 there is a separate NLM protocol with lockd running on both NFS client and server. Also statd should run on both (restores locks after a system boot).

Not running NFS locking runs surprisingly well.
Bash and tcsh lock their history files - absolute unnecessary!

Yes, I do have NFSv3.

Code:

$ nfsstat -m
/nfs/home from server:/export/home
 Flags:	rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=ip.of.the.server,mountvers=3,mountport=41268,mountproto=udp,local_lock=all,addr=ip.of.the.server

I have not been able to find a "lockd" daemon on my systems (Ubuntu 16.04). Is it part of rpc or nfs?

I found statd to be part of rpc. And rpc-statd was running on my client.

Code:

$ sudo systemctl status rpc-statd
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/lib/systemd/system/rpc-statd.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-08-18 10:54:06 CDT; 1 day 20h ago
  Process: 2022 ExecStart=/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=0/SUCCESS)
 Main PID: 2024 (rpc.statd)
   CGroup: /system.slice/rpc-statd.service
           └─2024 /sbin/rpc.statd --no-notify

Aug 18 10:54:06 client systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Aug 18 10:54:06 client rpc.statd[2024]: Version 1.2.8 starting
Aug 18 10:54:06 client rpc.statd[2024]: Flags: TI-RPC
Aug 18 10:54:06 client systemd[1]: Started NFS status monitor for NFSv2/3 locking..

But it seems it was not on server?

Code:

$ sudo systemctl status rpc-statd
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/lib/systemd/system/rpc-statd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

I'll see if enabling that makes the difference.

I'll only be able to check the GUI login on Tuesday, not before. So I'll post the results after that.

Thanks,

MadeInGermany · 08-23-2017, 05:23 AM

Maybe a bug in Ubuntu 16?
See this thread

I dislike the "kernel-nfs" adventure; again they give up a piece of compatibility with the modular Unix.
While kernel.org is still better than the one way road entered by systemd...(Welcome in dependency hell!)