Bug 31391

Please say whether this is an exact situation which used to work, but has stopped working; or whether you are trying something new - and if so, what.
So 154.103.234.24 is the host, and 154.103.234.0/26 includes the client.

CC'ing Herman in case he has the time to look at this.

CC: (none) => herman.viaene, lewyssmith

It worked in the past. I rebooted the machine by unmouting all of the nfs fiels from the clients then rebooted, and when I tried to remont the clients I got this problem. 
I tried nfs mounting the filesystem on the machine indo itself using 
mount -t nfs /local indo:/local1 
and again got the "no such file or directory" 
Here is df output. (varspoolmail1 is a cryptmount encrypted file)


devtmpfs                    4001332         0   4001332   0% /dev
tmpfs                       4013016     29196   3983820   1% /dev/shm
tmpfs                       4013016      1436   4011580   1% /run
/dev/sda6                  21200240  17251852   2846112  86% /
tmpfs                       4013020       824   4012196   1% /tmp
/dev/sda1                  20900920   7084544  12729312  36% /mga5
/dev/sda7                 189300892 151305096  28353728  85% /fastlocal
/dev/sdb6                 309975796  31129336 263074016  11% /other
/dev/sdb1                 806138616 277979924 487182636  37% /local
/dev/sdb5                 806138248 578899196 186263012  76% /extra
tmpfs                        802600       116    802484   1% /run/user/1000
/dev/mapper/varspoolmail1   1980080    732376   1145304  40% /var/spool/mail

I checked my setup vs. this one. I note differences in the fstab on the client side: I use the "user" parameter, but I don't have nofail and bg. But that is peanuts AFAICS.
What strikes me as weird is that w unruh mounts on a folder that is not empty. At least in my setup there are a few non-empty folders in /usr/local. Has the behavior of NFS been changed in that area????

Thanks Herman for looking.
(In reply to w unruh from comment #2)
> It worked in the past. I rebooted the machine by unmouting all of the nfs
> files from the clients then rebooted, and when I tried to remont the clients
> I got this problem. 
Something has changed, but it may be the way you are doing things.
Does your setup, all machines, normally run permanently?
Exactly how are/were the client machines mounting the server directory?
- At boot from fstab? This looks the case from your example client fstab line in comment 0, since without the option 'noauto' it should be mounted at boot.
- Manually as you show in comment 0?

On both the server & client systems to see whether any of the software has changed recently, perhaps try:
 $ rpm -qa --last | grep nfs
which should list all the NFS pkgs you have (possibly + a few others) with their latest dates. Does this give a clue as to whether any relevant pkg has been recently updated, and to which you can relate the problem?

> On the server I have
> ls -ld /local/usrlocal 
> drwxr-xr-x 76 root root 4096 Jul 31  2020 /local/usrlocal/
> In /etc/exports
> /local/usrlocal 154.103.234.0/26(fsid=21,no_subtree_check,rw,no_root_squash)
which confirm the existence and exporting of the shared directory.

(In reply to Herman Viaene from comment #3)
> What strikes me as weird is that w unruh mounts on a folder that is not
> empty. /usr/local
Indeed, it would be rare for this directory not to be crowded. Mount allows this, I believe: the previous contents become 'hidden', and replaced for the duration by the mounted filesystem.

Can you comment, Bill?

Your example in comment 2:
 mount -t nfs /local indo:/local1           [indo=server?]
looks like mounting a local directory on another directory on the same machine where the mount point is both network-defined and not evident in the df list. I do not get it, but it is probably irrelevant here.

> In /var/log/syslog I just get
> Jan 10 21:34:59 indo rpc.mountd[3987]: authenticated mount request from
> 154.103.234.24:735 for /local/usrlocal (/local/usrlocal)
On the server? Looks OK if that IP address is that of a client machine. (My comment 1 was wrong on this point).

Yes, the mount on /usr/local is over a directory with contents. It does/did hide those original  contents when the directory is mounted over it. 

indo is the server. The mount -t nfs /local indo:/local1 was run on the server and did not work. That was simply a test to see if even the server could not see /local via nfs. It could not. So somehow nfs wasn't seeing anything on the server.

I finally got tired of trying to debug this and tried rebooting again (these problems began on the a reboot on Monday). Now most of clients can mount the directories-- except one client is still reporting "permission denied", on a couple of the directories (but works with others) when the permissions for it are exactly the same as for every other client (including in /etc/exports)

This whole thing is just bizarre, but in the meantime I have kludged that one one client.
So things are working now, kludged and with no faith that it will continue working on the next reboot.

I guess since the system is working now, it would be best to close this. 
However what amazes me is how little degugging information there is for nfs. If the server was delivering a message to the client of "no such file or directory" then I would expect some message on the server corresponding to that, but all that I can find is a message saying everything worked.

Instead of "mount -t nfs /local indo:/local1" shouldn't it
have been  mount -t nfs indo:/local1 /local"?

From "man mount"
mount [-fnrsvw] [-t fstype] [-o options] device mountpoint

CC: (none) => davidwhodgins

Yes. Misprint. I did it correctly during the test.

Did you ever do what I asked in comment 4 :
> On both the server & client systems to see whether any of the software
> has changed recently, perhaps try:
> $ rpm -qa --last | grep nfs
> which should list all the NFS pkgs you have (possibly + a few others)
> with their latest dates. Does this give a clue as to whether any relevant
> pkg has been recently updated, and to which you can relate the problem?
From comment 5:
> (these problems began on the a reboot on Monday)
suggests that they were spontaneous.

> Now most of clients can mount the directories-- except one client is still
> reporting "permission denied", on a couple of the directories (but works
> with others) when the permissions for it are exactly the same as for every 
> other client (including in /etc/exports)
All very frustrating, but progress in the right direction. Unless the situation degrades again, we should be able to close this works-for-me (you!).

Have you tried sounding the forum? You would need to be concise about what you recount.

Closing

Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED