Hello,
I have set up a thin client (running LuPu 520) as an NFS server, running 24/7, uptime several months, mounted and exported an USB drive, and now I am having trouble to access the export with one of my laptops. The wole thing works flawless with my first Laptop ThinkPad R500, WiFi, running Fatdog610, with my desktop, also fatdog610 and with the kids' desktop, LuPu528, both desktops and the thin client via 100mbit ethernet.
The Laptop in question, ThinkPad T60P is running slacko 5.6, frugal install, pretty much as it came, nfs-utils installed, is connected over WiFi, and does connect and mount the exported drive, after the server has been restarted, and then, after unpredictable spans of time, mounting gives a 'permission denied' error. While at the same time all other clients have no trouble mounting and accessing the exported drive, and showmount -e and rpcinfo give the expected output. All other network related stuff on the Laptop is still functional, too. The problem remains, whether I use manual mount or an entry in fstab. After issueing an 'rc.nfsd restart' on the server, everything is back to normal instantly (i.e. without rebooting or anything restarting on the laptop).
On the server I entered the whole subnet (192.168.178.0/24) in hosts.allow and in exportfs and used 'no_root_squash'.
I am somewhat out of my wits here, anything else to think about?
[S O L V E D]Unable to access NFS drive from client laptop
[S O L V E D]Unable to access NFS drive from client laptop
Last edited by chiron on Mon 23 Dec 2013, 17:21, edited 1 time in total.
are you using the NFS utils matching the slacko version...ie recent slackware. There are changes though in my case i could not connect at all with slax 7 until I updated them. 'mount' in slacko may not be a matching version either...puppy tends to have older core binaries.slacko 5.6, frugal install, pretty much as it came, nfs-utils installed,
Would be hard to suggest a server fault since everything else is fine.
Only other thought might be NFS version...I think I am normally using NFS3 for linux and windows clients but perhaps slacko is using 4 and the server is not happy with it.
Is the wifi solid on the laptop...a flaky connection could be causing this. (had this problem with older b43 for example...fine for the internet but cut off when using the LAN.)
mike
Are you using hard or soft mounts?
Just ideas that came to mind...never had a similar problem...once I sort out connection it behaves.
dmesg may give some clues..
mike
Just now I wanted to access some files with my laptop, the one I wrote works all the time, and now have the same behavior. After three days of functioning, shuffling files to and fro, I now get 'access denied by server while mounting' Done nothing to the server, nothing changed on the R500, except it was in 'suspend to ram' for the night. WiFi on the R500 is rock-solid, I stream audio over ssh from it, and don't have glitches or any problems.
IP-addresses are always the same for all computers, set over DHCP by the router according to MAC-address.
Seems like a server related problem now. Need to look into the server logs and stuff later on.
IP-addresses are always the same for all computers, set over DHCP by the router according to MAC-address.
Seems like a server related problem now. Need to look into the server logs and stuff later on.
yes ... you seem to have as much grasp on this as anyone here is likely to do.Seems like a server related problem now. Need to look into the server logs and stuff later on.
... perhaps take it literally...ie something is wrong with the share... disk or file system errors possibly..access denied by server while mounting
closest i get is when windows is sharing... its implementation of NFS , networking under load and usb diskhandling is not the greatest and thats when I sometimes get problems accessing .In that case I think it does not get on too well with the drive going to sleep when not being accessed (workstation that gets rebooted every day sharing a usb drive so not too unlike your setup)
mike
Looked up dmesg on the server, only activity I saw was my usb-keyboard plugged in. When I went further back, I stumbled upon some nfsd-related messages, something in the line of 'flushing exports cache' and something about nfsdv4, although, as far as I am aware of it, I only use vers=3. Might dive into nfsd config file and force version to 3. And maybe disable the flushing, any idea what it is useful for?
USB Drive going to sleep wouldn't explain, why it works on all machines except for one, but I checked, and from the flashing light, it appears active.
USB Drive going to sleep wouldn't explain, why it works on all machines except for one, but I checked, and from the flashing light, it appears active.
Now it's the other way 'round, the T60 gets access, while the R500 get's access denied by server.
mount command gives me the following:
Then I set vers=3
The .31 is the IP of the server, the R500's IP is .108. showmount on the R500 now returns:
which is somewhat weird, because the T60's IP is .33. 'noname' and 'puppypc' resolve to .20 and .30, don't know why they are in the list, I did all configuring with IP-addresses, and them both are not even running ATM.
All those commands issued on the R500, while at the same time, mounting gives 'access denied by server' and, also at the same time, the T60 does have access, but the T60 IP does not show up in showmount. Issueing the commands on the T60 gives the same results, BTW.
Both ThinkPads are connected to the same wireless router and are both in one room ATM, best WiFi connection.
dmesg on the server does not return anything nfs-related, apart from 'flushing the cache', no successful connects, no denied requests.
I will reboot he server now again, bit of a hassle, it's the machine that manages light/heat/water in my terrarium, too (and is very reliable in that respect).
mount command gives me the following:
Code: Select all
# mount 192.168.178.31:/mnt/nas /root/nas -v -o nolock
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Wed Dec 18 13:46:21 2013
mount.nfs: trying text-based options 'nolock,vers=4,addr=192.168.178.31,clientaddr=192.168.178.108'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.178.31:/mnt/nas
Code: Select all
# mount 192.168.178.31:/mnt/nas /root/nas -v -o nolock -o vers=3
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Wed Dec 18 13:47:33 2013
mount.nfs: trying text-based options 'nolock,vers=3,addr=192.168.178.31'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.178.31 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.178.31 prog 100005 vers 3 prot UDP port 974
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.178.31:/mnt/nas
Code: Select all
# showmount -a 192.168.178.31
All mount points on 192.168.178.31:
192.168.178.108:/mnt/nas
192.168.178.20:/mnt/nas
192.168.178.24:/mnt/nas
192.168.178.30:/mnt/nas
noname:/mnt/nas
puppypc:/mnt/nas
Code: Select all
# showmount -e 192.168.178.31
Export list for 192.168.178.31:
/mnt/nas 192.168.178.0/24
Code: Select all
# rpcinfo -p 192.168.178.31
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 952 rquotad
100011 2 udp 952 rquotad
100011 1 tcp 953 rquotad
100011 2 tcp 953 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 50194 nlockmgr
100021 3 udp 50194 nlockmgr
100021 4 udp 50194 nlockmgr
100021 1 tcp 33074 nlockmgr
100021 3 tcp 33074 nlockmgr
100021 4 tcp 33074 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100005 1 udp 974 mountd
100005 1 tcp 975 mountd
100005 2 udp 974 mountd
100005 2 tcp 975 mountd
100005 3 udp 974 mountd
100005 3 tcp 975 mountd
100024 1 udp 40312 status
100024 1 tcp 36710 status
Both ThinkPads are connected to the same wireless router and are both in one room ATM, best WiFi connection.
dmesg on the server does not return anything nfs-related, apart from 'flushing the cache', no successful connects, no denied requests.
I will reboot he server now again, bit of a hassle, it's the machine that manages light/heat/water in my terrarium, too (and is very reliable in that respect).
showmount -a returns some sort of mount history that has never made any sense whatsoever for me...I fail to see it being of any use whatsoever for diagnosis so best disregard it.
I noticed you use nolock... the server appears to have the lock modules loaded so just wondered? Is it because the clients do not?
Have you checked there are no firewall joke funnies going on in either the server, router or clients.... its does seem odd that the clients denied keep changing.
Another factor would be a changing exports list or host.allow file which is highly unlikely. exportfs should give a list of current exports (on the server) along with ip range.
Are all the clients showing a nice full list for rpcinfo ?
mike
I noticed you use nolock... the server appears to have the lock modules loaded so just wondered? Is it because the clients do not?
Have you checked there are no firewall joke funnies going on in either the server, router or clients.... its does seem odd that the clients denied keep changing.
Another factor would be a changing exports list or host.allow file which is highly unlikely. exportfs should give a list of current exports (on the server) along with ip range.
Are all the clients showing a nice full list for rpcinfo ?
mike
I do get the full rpc list on all clients, even on the one that gets denied access.
When I rebooted the server, I screwed up a bit with the scripts, and so tried connecting while the share was not mounted in place. So I got the same error, access denied by server. After I mounted the USB drive correctly, and restarted nfsd, now again all works well, for the time being. So it could also be I have trouble outside of nfsd, but then why does one client connect, the other not?
I use nolock, because when mounting without nolock, I got complains about statd not running.
When I rebooted the server, I screwed up a bit with the scripts, and so tried connecting while the share was not mounted in place. So I got the same error, access denied by server. After I mounted the USB drive correctly, and restarted nfsd, now again all works well, for the time being. So it could also be I have trouble outside of nfsd, but then why does one client connect, the other not?
I use nolock, because when mounting without nolock, I got complains about statd not running.
.When I rebooted the server, I screwed up a bit with the scripts, and so tried connecting while the share was not mounted in place. So I got the same error, access denied by server
Well one earlier thought was if the mounted drive was say randomly appearing to be read only that would deny a read/write mount....so perhaps give the drive behaviourr closer scrutiny. Can you share another drive to compare results...even if its just a flash stick?
/usr/sbin/rpc.statd ... sounds like its not running or needed module absent... for the nolock... do not think this is related just something I normally have enabled. Apparently its to avoid multiple users modifying he same file at the same time which is unlikely to apply for some systems.
mike
Thanks for the help and ideas so far, but I'm about to give up on nfs. The whole thing worked with ftpd and curlftpfs, well with the known problems and restrictions. But it DID what I expected. Needed a more reliable and less error-prone way of sharing files, since my wive wants to take part in this network now, too. And, actually, I got hooked on the idea to have all my manuals, reference designs, datasheets ... in one place, accessible by any computer in the house, without the frills of curlftpfs 
Guess next thing to try will be samba, which is supposed to be more complicated. When I have more leisure, I might go back to nfs and really thoroughly do all the troubleshooting, but right now, a working out of the box solution is more my friend.
Guess next thing to try will be samba, which is supposed to be more complicated. When I have more leisure, I might go back to nfs and really thoroughly do all the troubleshooting, but right now, a working out of the box solution is more my friend.No problem...I used NFS after frustrations with curlftpfs and it has 'served' me well ever since.
There is some undelying problem and unfortunately we have not found it ... perhaps revisiting it at somepoint may reveal all.
never tried samba... don't really have the urge since its something I avoided on windows too.
One other thought...have you tried sshfs... I only recently did and its rather neat. Although it apparently is using ftp it mounts and shares transparently like NFS with no caching that I have detected.
sshfs host:/mnt/point /local/mnt
then a password..done... Its part of the sshd package...standard puppies only have ssh.
mike
There is some undelying problem and unfortunately we have not found it ... perhaps revisiting it at somepoint may reveal all.
never tried samba... don't really have the urge since its something I avoided on windows too.
One other thought...have you tried sshfs... I only recently did and its rather neat. Although it apparently is using ftp it mounts and shares transparently like NFS with no caching that I have detected.
sshfs host:/mnt/point /local/mnt
then a password..done... Its part of the sshd package...standard puppies only have ssh.
mike
Just a little update ...
I tried booting the T60 to LuPu 528, mounting the share failed. I booted yet another Laptop (in my garage, hasn't been in the game yet at all) to Lupu 5.28, success, without anything changed about LuPu installation, except connection to WLAN. The server was up and nothing got changed there.
And now, finally, I changed the IP-Adress of the T60, from .33 to .114 and it again was able to mount the shared drive. Nothing changed on the server, and the T60 not even rebooted, just reconnected with new IP. So I guess, the server blocks the IP after a while. But why? I allowed the whole subnet in hosts.allow, I expoerted the share to the whole subnet, and, after a fresh start of nfsd it works for a while, and then blocks the IP. Does the T60 secretly perform a DOS attack on the nfs-Server? (not seriously). I am pretty sure the firewall on the nfs server is disabled, as on all local machines, we live behind a quite restrictive (i.e. all ports closed) router.
I tried booting the T60 to LuPu 528, mounting the share failed. I booted yet another Laptop (in my garage, hasn't been in the game yet at all) to Lupu 5.28, success, without anything changed about LuPu installation, except connection to WLAN. The server was up and nothing got changed there.
And now, finally, I changed the IP-Adress of the T60, from .33 to .114 and it again was able to mount the shared drive. Nothing changed on the server, and the T60 not even rebooted, just reconnected with new IP. So I guess, the server blocks the IP after a while. But why? I allowed the whole subnet in hosts.allow, I expoerted the share to the whole subnet, and, after a fresh start of nfsd it works for a while, and then blocks the IP. Does the T60 secretly perform a DOS attack on the nfs-Server? (not seriously). I am pretty sure the firewall on the nfs server is disabled, as on all local machines, we live behind a quite restrictive (i.e. all ports closed) router.
Definately an odd one and nothing i have experienced with NFS. If an ip is allowed...its allowed...end of story.
My router likes to kicks wifi connections off after 10 minutes of inactivity...I ping it every 5. Apparently a known firmware problem but its from the isp and they have no updates for their custom model. It also has the option to periodically block ports/ips as part of its firewall.
Not saying this is what's happening but its the only other link in your network chain and it might just be playing at being awkward.
Another thought it that if the T60 does get blocked for whatever reason that may affect other methods of file sharing anyway.
So it gets blocked after a while...cause unknown. Anything in logs including the router log?(may need enabling)
mike
My router likes to kicks wifi connections off after 10 minutes of inactivity...I ping it every 5. Apparently a known firmware problem but its from the isp and they have no updates for their custom model. It also has the option to periodically block ports/ips as part of its firewall.
Not saying this is what's happening but its the only other link in your network chain and it might just be playing at being awkward.
Another thought it that if the T60 does get blocked for whatever reason that may affect other methods of file sharing anyway.
So it gets blocked after a while...cause unknown. Anything in logs including the router log?(may need enabling)
mike
Shame on me ...
on the server I disabled klogd, so it doesn't write to the internal flashdisk all the time. Not much wonder, I did not find any nfs related entries. Restartted klogd for the time being, and tried to mount with the T60, et voila:
when I try to mount with IP set to 192.168.178.33, I get an rpc entry, telling me first 'authenticated mount request from noname:708', then 'getfh failed'. So no mounting takes place. I don't know where the 'noname' enters the game yet, but sure I did not call any of my puters that. And, most likely the name resolves to an IP that is not valid, and thus does not get a filehandle. Understood the whole problem so far, now I go hunting for the 'noname', puppy never calls itself 'noname' in a network, so it might be the router, that did assign 'noname' to the T60 while we were configuring it. Light at the end of the tunnel
on the server I disabled klogd, so it doesn't write to the internal flashdisk all the time. Not much wonder, I did not find any nfs related entries. Restartted klogd for the time being, and tried to mount with the T60, et voila:
when I try to mount with IP set to 192.168.178.33, I get an rpc entry, telling me first 'authenticated mount request from noname:708', then 'getfh failed'. So no mounting takes place. I don't know where the 'noname' enters the game yet, but sure I did not call any of my puters that. And, most likely the name resolves to an IP that is not valid, and thus does not get a filehandle. Understood the whole problem so far, now I go hunting for the 'noname', puppy never calls itself 'noname' in a network, so it might be the router, that did assign 'noname' to the T60 while we were configuring it. Light at the end of the tunnel
Still working flawless. I don't know, where the 'noname' originated, but I won't bother, I don't need it perfect, I need it working
Take home message: looking into server-side logs is always a good idea ... especially after you turn logging ON.
Take home message II: Frisbee works really good, but does have problems assigning static IPs, and probably calls itself 'noname' in the network.
Well, thanks again for the brainstorming
Take home message: looking into server-side logs is always a good idea ... especially after you turn logging ON.
Take home message II: Frisbee works really good, but does have problems assigning static IPs, and probably calls itself 'noname' in the network.
Well, thanks again for the brainstorming