Description of problem:I have a Mga8 server and an MGA8 client. On the server the directory is exported. On the client it is in /etc/fstab. But when I do mount -a I get an error on the client. buton:10.0[root]>mount /usr/local mount.nfs: mounting indo:/local/usrlocal failed, reason given by server: No such file or directory In /etc/fstab on the client I have indo:/local/usrlocal /usr/local nfs nofail,rw,rsize=8192,wsize=8192,soft,bg 0 0 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) (and yes the client in in that net block) 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) and no other error message. I have given one sample but all the mounts from indo are refused in the same way or with access denied by server while mounting What could be the problem? rsion-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
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) => WORKSFORMEStatus: NEW => RESOLVED