.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
On Fri, Apr 13, 2018 at 3:34 PM, Bob Goodwin bobgoodwin@fastmail.us wrote:
.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_chec k,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
-- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Firewall? Probably closed by default.
On 04/13/18 15:36, Terry Polzin wrote:
Firewall? Probably closed by default.
.
I just tried stopping firewalld and selinux at either computer, client and server, one at a time, but it would not connect with any one of them stopped.
On 13/04/18 20:34, Bob Goodwin wrote:
.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
Not an expert myself, but I can't see anything there that says you've opened up the NFS ports on the NFS server
On 04/13/18 15:37, Danny Horne via users wrote:
I can't see anything there that says you've opened up the NFS ports on the NFS server
I have another NFS server that's always running and works so I think the required ports are open.
Firewall? Probably closed by default.
May be a firewall problem, but if it works with one NFS server? I'll try stopping firewalld, although I think I have already done that a few days ago, need to be sure.
Bob
On 13/04/18 20:34, Bob Goodwin wrote:
.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
Sorry, meant to say firewall ports
On 04/13/2018 12:39 PM, Danny Horne via users wrote:
On 13/04/18 20:34, Bob Goodwin wrote:
.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
Sorry, meant to say firewall ports
By default F27 uses NFSv4. The access is far more restrictive. If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
/home/public 192.168.1.0/24(rw,no_root_squash)
Otherwise the server will try to demote the root user down to the anonymous user, who probably doesn't have R/W access to /home/public (or whatever export you've specified).
Make sense? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - They say when you play a Microsoft CD backwards, you'll hear - - Satanic messages, but if you play it forwards, it will install - - Windows...which means Satan is in your system. - ----------------------------------------------------------------------
On 04/13/18 16:57, Rick Stevens wrote:
By default F27 uses NFSv4. The access is far more restrictive. If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
/home/public 192.168.1.0/24(rw,no_root_squash)
Otherwise the server will try to demote the root user down to the anonymous user, who probably doesn't have R/W access to /home/public (or whatever export you've specified).
Make sense?
.
Just adding "no_root_squash" did not help, it still reports refused.
Sometimes it seems nothing is ever easy, at least with NFS.
Thanks,
On 04/14/18 06:16, Bob Goodwin wrote:
On 04/13/18 16:57, Rick Stevens wrote:
By default F27 uses NFSv4. The access is far more restrictive. If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
/home/public 192.168.1.0/24(rw,no_root_squash)
Otherwise the server will try to demote the root user down to the anonymous user, who probably doesn't have R/W access to /home/public (or whatever export you've specified).
Make sense?
.
Just adding "no_root_squash" did not help, it still reports refused.
Sometimes it seems nothing is ever easy, at least with NFS.
I hadn't set up an nfs server in a while so I did the following.
Server Side:
Created /etc/exports with the following contents
/var/ftp 192.168.1.0/24(rw,async,no_wdelay,no_root_squash)
Checked the nfs box in the firewalld settings
systemctl enable nfs-service (only need that if you want the service started at boot) systemctl start nfs-service
Client side:
mount 192.168.1.191:/var/ftp /mnt
Result:
[root@meimei mnt]# df -T | grep mnt 192.168.1.191:/var/ftp nfs4 29098240 17908736 9688320 65% /mnt
I suppose, that this point, you should run on the Server side
systemctl status nfs-server
On 04/13/2018 04:01 PM, Ed Greshko wrote:
On 04/14/18 06:16, Bob Goodwin wrote:
On 04/13/18 16:57, Rick Stevens wrote:
By default F27 uses NFSv4. The access is far more restrictive. If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
/home/public 192.168.1.0/24(rw,no_root_squash)
Otherwise the server will try to demote the root user down to the anonymous user, who probably doesn't have R/W access to /home/public (or whatever export you've specified).
Make sense?
.
Just adding "no_root_squash" did not help, it still reports refused.
Sometimes it seems nothing is ever easy, at least with NFS.
I hadn't set up an nfs server in a while so I did the following.
Server Side:
Created /etc/exports with the following contents
/var/ftp 192.168.1.0/24(rw,async,no_wdelay,no_root_squash)
Checked the nfs box in the firewalld settings
systemctl enable nfs-service (only need that if you want the service started at boot) systemctl start nfs-service
Client side:
mount 192.168.1.191:/var/ftp /mnt
Result:
[root@meimei mnt]# df -T | grep mnt 192.168.1.191:/var/ftp nfs4 29098240 17908736 9688320 65% /mnt
I suppose, that this point, you should run on the Server side
systemctl status nfs-server
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Have you tried showmounts -e 192.168.1.x to see if the nfs server is exporting the directories.
e.g. I get howmount -e taurus Export list for taurus: /export * /export/home1 127.0.0.0/8,192.168.21.0/24 /export/home0 127.0.0.0/8,192.168.21.0/24
My exports looks like this:
/export *(fsid=0,crossmnt,rw,root_squash,sync,no_subtree_check) /export/home0 192.168.21.0/24(rw,root_squash,sync,no_subtree_check) 127.0.0.0/8(rw,root_squash,sync,no_subtree_check) /export/home1 192.168.21.0/24(rw,root_squash,sync,no_subtree_check) 127.0.0.0/8(rw,root_squash,sync,no_subtree_check)
I believe you need the first line since nfs version 3
On 04/13/2018 04:38 PM, Joseph Loo wrote:
Have you tried showmounts -e 192.168.1.x to see if the nfs server is exporting the directories.
Note that showmounts uses the portmapper. It may only work if your system supports the use of NFSv3. If you're using only NFSv4, and don't have the portmapper services running, you cannot use showmounts.
My exports looks like this:
/export *(fsid=0,crossmnt,rw,root_squash,sync,no_subtree_check) /export/home0 192.168.21.0/24(rw,root_squash,sync,no_subtree_check) 127.0.0.0/8(rw,root_squash,sync,no_subtree_check) /export/home1 192.168.21.0/24(rw,root_squash,sync,no_subtree_check) 127.0.0.0/8(rw,root_squash,sync,no_subtree_check)
I believe you need the first line since nfs version 3
Since version 4. V3 did not require a root export.
On 04/13/2018 07:01 PM, Ed Greshko wrote:
On 04/14/18 06:16, Bob Goodwin wrote:
On 04/13/18 16:57, Rick Stevens wrote:
By default F27 uses NFSv4. The access is far more restrictive. If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
/home/public 192.168.1.0/24(rw,no_root_squash)
Otherwise the server will try to demote the root user down to the anonymous user, who probably doesn't have R/W access to /home/public (or whatever export you've specified).
Make sense?
.
Just adding "no_root_squash" did not help, it still reports refused.
Sometimes it seems nothing is ever easy, at least with NFS.
I hadn't set up an nfs server in a while so I did the following.
Server Side:
Created /etc/exports with the following contents
/var/ftp 192.168.1.0/24(rw,async,no_wdelay,no_root_squash)
Checked the nfs box in the firewalld settings
systemctl enable nfs-service (only need that if you want the service started at boot) systemctl start nfs-service
Client side:
mount 192.168.1.191:/var/ftp /mnt
Result:
[root@meimei mnt]# df -T | grep mnt 192.168.1.191:/var/ftp nfs4 29098240 17908736 9688320 65% /mnt
I suppose, that this point, you should run on the Server side
systemctl status nfs-server
This was probably already suggested, but: -- on the server side, run "sudo netstat -antp | grep 111" to see if the nfs server is there & listening. -- on the client side, try the classic "telnet <server_name> 111" to see if you can at least connect.
*Mark C. Allman, PMP, CSM* Founder, See How You Ski, www.seehowyouski.com http://www.seehowyouski.com Sr. Project Manager, Allman Professional Consulting, Inc., www.allmanpc.com http://www.allmanpc.com 617-947-4263, Twitter: @allmanpc
On 04/13/2018 04:38 PM, Mark C. Allman wrote:
This was probably already suggested, but: -- on the server side, run "sudo netstat -antp | grep 111" to see if the nfs server is there & listening. -- on the client side, try the classic "telnet <server_name> 111" to see if you can at least connect.
Port 111 is the portmapper service, which isn't used in NFSv4.
On 04/13/2018 01:57 PM, Rick Stevens wrote:
By default F27 uses NFSv4. The access is far more restrictive.
I tend to think it is less so, since it uses fewer ports, which are predictable. That wasn't the case with v3 and older, which tended to require much more permissive firewall policies.
If you're NFS mounting a filesystem as a normal user on the client, then you have to make sure that user has the same UID and GID on the server and has access to that exported directory.
NFSv4 uses idmap, so UID and GID mapping are unnecessary. In v3 and older, they needed to match.
If you're mounting it as root on the client (as seems to be true by the "#" in the example command), make sure you add "no_root_squash" to the export at the server:
Mounting an NFS filesystem can only be done by root on a typical UNIX system, since the NFS client is in the kernel, not in userspace. The no_root_squash doesn't affect mounting at all, only accessing files after a filesytem is mounted.
On Fri, Apr 13, 2018 at 3:34 PM, Bob Goodwin bobgoodwin@fastmail.us wrote:
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Does "192.168.1.0/255.255.255.0" work?!
The prefix is usually "24" not "255.255.255.0".
On Fri, Apr 13, 2018 at 10:03 PM, Earl Ramirez earlaramirez@gmail.com wrote:
Does "192.168.1.0/255.255.255.0" work?!
The prefix is usually "24" not "255.255.255.0".
Yes, that also works NFS supports both contiguous mask length and prefix.
Now that you mention it, my memory's clearer about this. I should've remembered because I've been using nfs for along time! Thanks.
On Fri, 2018-04-13 at 15:34 -0400, Bob Goodwin wrote:
.
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
Are you able to mount the share locally on the server that is hosting the shares?
On 04/13/2018 07:11 PM, Earl Ramirez wrote:
On Fri, 2018-04-13 at 15:34 -0400, Bob Goodwin wrote:
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
There is an ethernet path between them on my lan, ssh works from each computer to the other ...
Perhaps a problem with bind, I don't know how to troubleshoot this, would appreciate suggestions.
Bob
Are you able to mount the share locally on the server that is hosting the shares?
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
are you missing a "/" on va/ftp.pub on your 4th line on the cat /etc/exports?
Try a showmount -e 192.168.1.86
this will help determine if the directories are actually exported. Don't forget to restart the nfs server whenever you do changes on the /etc/exports.
On 04/13/18 15:34, Bob Goodwin wrote:
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw)
var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check)
/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
+
Using the information I received here I have the server connecting now, except that I need to set the firewall to allow nfs. The problem was that I followed the routine described in "Fedora Administration_Guide_Draft/NFS" and assumed it was creating the files displayed. I was mislead there.
"/var/ftp/pub" etc did not exist in my server, they were only in the examples given in the instructions.
So I created /export/home and a new /etc/exports using a line from my working NFS system:
# cat /etc/exports /exports/home 192.168.1.0/24(ro,sync,insecure,no_root_squash,no_subtree_check,fsid=0)
Once that was done I was able to connect to the server and see an empty test file I put into /exports/home/
# ll /mnt/test/ total 0 -rw-r--r--. 1 root root 0 Apr 14 11:52 zzztest
I received an overwhelming response to my query, all very helpful, which I will save in my notes for the next time I do this. My objective now is to use the new computer while I rework the old server. I think I should be able to finish the effort with what I have now.
Thanks to everyone responding,
Bob
On 04/13/2018 12:34 PM, Bob Goodwin wrote:
I am attempting to set up an NFS server on a new Fedora 27 computer I have assembled using instructions I found, "Fedora Administration_Guide_Draft/NFS" and I am having a problem accessing it.
Sadly, that document is both incomplete and badly out of date.
$ cat /etc/exports /var/ftp/pub 192.168.1.0/255.255.255.0(ro) /home/public 192.168.1.0/255.255.255.0(rw) var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_subtree_check) /var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Several things to note:
1: NFSv4 is the default option on contemporary Fedora systems. In NFSv4, the first export must be a "root" for all other exports. That is, if your first export is /var/ftp/pub, then all subsequent exports *must* be a subdirectory of /var/ftp/pub. Typically, /export is the first export listed, and subdirectories follow. 2: The third line lacks a leading "/" and will cause exportfs to print an error. I'm mostly sure that line is simply disregarded. 3: It doesn't make sense to export one directory twice, to the same set of clients. If you fix the missing leading "/" on the third line, I'm mostly sure the fourth will then be disregarded.
You probably want:
/export 192.168.1.0/255.255.255.0(ro,sync) /export/var/ftp/pub 192.168.1.0/255.255.255.0(ro,sync) /export/home/public 192.168.1.0/255.255.255.0(rw,sync) /export 192.168.54.0/255.255.255.0(ro,sync) /export/var/ftp/pub 192.168.54.0/255.255.255.0(ro,sync,no_wdelay,no_subtree_check,nohide)
Then from the client I get a refusal:
# mount 192.168.1.86:/home/public /mnt/test/ mount.nfs: Connection refused
Using NFSv4, the client must be able to reach TCP port 2049. You can verify that this is or is not the case using telnet at the client. Make sure the service is running, and port 2049 is open on the server. (Use "ss -t -l -n" on the server and look for port 2049.) Telnet to that port from the client.