Access denied for NFS - but hosts.allow and hosts.deny seem OK
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Access denied for NFS - but hosts.allow and hosts.deny seem OK
I have a server running IPFire that is running our internet, and also running a PXE boot server. The end result of this is that we will be able to boot Ubnutu over the network, but it needs NFSv4 to work.
The IPfire addon documentation for NFS is simple to the extreme and claims it should just work. Which it doesn't.
sshd : ALL
ALL : localhost
ALL : 10.10.0.0/255.255.0.0
the contents of the /etc/hosts.deny file:
ALL:ALL
The way I read that is that any machine with an ip address starting 10.10 should always be allowed access.
Also, after a little googling I discovered that sometimes, an NFS server will act oddly if the remote user doesn't have local access to the folder you're mounting, so I changed the folders group to 'nobody' and run 'chmod 777' on it (not exactly security conscious, but I'll fix that later).
Howerver, every time I run 'mount 10.10.10.1:/mnt/sdb1/tftpboot/ /mnt/nfs' on a client (which has the ip 10.10.10.111) I get: ' access denied by server while mounting 10.10.10.1:/mnt/sdb1/tftpboot'
'rpcinfo -p' (on the client and the server) reports that port 2049 is open and NFS is listening on it, and I can telnet to that port (meaning the firewall isn't interfering with it).
I have tried restarting the nfs-server daemon on the server, and it does restart, but when it's stopping the NFS-statd daemon it reports "FAILED", although it starts correctly. I don't know if that makes any difference.
Have you seen the "Linux NFS-HOWTO"? You may have a local copy, otherwise here is a link. http://nfs.sourceforge.net/nfs-howto/
Chapter 3 details the configuration for a server.
The entry you have made in hosts.deny says that you are denying the access of all the machines except the one you have mentioned in your hosts.allow file
but your hosts.allow file seems to be incomplete
You need to mention the services and the hosts which are allowed to use those services through your machine
Code:
#vi /etc/hosts.allow
sshd : ALL
ALL : localhost
lockd: 10.10.10.111
rquotad: 10.10.10.111
mountd: 10.10.10.111
statd: 10.10.10.111
portmap: 10.10.10.111
sorry about the long wait: I've been busy with other things.
I tried your suggestion for changing the hosts.allow file, and then running "/etc/init.d/nfs-server restart" but it doesn't make any difference to the error message.
Also, replacing hosts.allow and hosts.deny with empty files and restarting the nfs-server makes no difference ether. According to the documentation I've read, this should just allow everyone by default, which it doesn't. So something else is fundamentally wrong somewhere, but I don't know what it is.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.