My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
Any help appreciated.
On 8/28/19 5:45 AM, Bob Goodwin wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
Any help appreciated.
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
On 8/27/19 5:51 PM, Ed Greshko wrote:
On 8/28/19 5:45 AM, Bob Goodwin wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
Any help appreciated.
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
. Good, that allows showmount to dis[lay the export list.
Thank you for that.
On 8/27/19 6:05 PM, Bob Goodwin wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
. Good, that allows showmount to dis[lay the export list.
. Now what is wrong with my mount command?
[root@box83 bobg]# mount 192.168.2.128 /home /etc/exports /mnt/testb mount: bad usage Try 'mount --help' for more information.
[root@box83 bobg]# showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
On 8/28/19 6:17 AM, Bob Goodwin wrote:
On 8/27/19 6:05 PM, Bob Goodwin wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
. Good, that allows showmount to dis[lay the export list.
. Now what is wrong with my mount command?
[root@box83 bobg]# mount 192.168.2.128 /home /etc/exports /mnt/testb mount: bad usage Try 'mount --help' for more information.
mount 192.168.2.128:/home /mnt/testb
the format is
mount from_where:what_to_mount mount_point
On 8/27/19 6:47 PM, Ed Greshko wrote:
mount 192.168.2.128:/home /mnt/testb
the format is
mount from_where:what_to_mount mount_point
. Of course that works.
Thanks Ed.
On Tuesday, August 27, 2019 2:45:42 PM MST Bob Goodwin wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
Any help appreciated.
-- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box83 FEDORA-30/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
The following two commands, in order, add the rule to your running config, and to your permanent firewall config:
firewall-cmd --add-service=nfs firewall-cmd --add-service=nfs --permanent
On 8/28/19 2:52 PM, John Harris wrote:
The following two commands, in order, add the rule to your running config, and to your permanent firewall config:
firewall-cmd --add-service=nfs firewall-cmd --add-service=nfs --permanent
That may not be sufficient depending on the zone an interface is assigned.
NFS-Server=f30k, NFS-Client=meimei The zone on NFS-Server is "home".
[root@f30-k ~]# firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: enp0s8 sources: services: dhcpv6-client mdns nfs nfs3 rpc-bind samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
[egreshko@meimei ~]$ showmount -e f30k rpc mount export: RPC: Timed out
But then....
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent success [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent success
And the result is
[egreshko@meimei ~]$ showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
Am 2019-08-28 09:20, schrieb Ed Greshko:
[ ... ]
[egreshko@meimei ~]$ showmount -e f30k rpc mount export: RPC: Timed out
But then....
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent success
Port 111 translates to the rpc-bind firewalld service which you had already permitted.
[root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent success
Port 20048 translates to the mountd firewalld service.
And the result is
[egreshko@meimei ~]$ showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
Alexander
On 8/28/19 4:27 PM, Alexander Dalloz wrote:
Am 2019-08-28 09:20, schrieb Ed Greshko:
[ ... ]
[egreshko@meimei ~]$ showmount -e f30k rpc mount export: RPC: Timed out
But then....
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent success
Port 111 translates to the rpc-bind firewalld service which you had already permitted.
Yes, I know. I'd forgotten I'd added that. Shoot me. :-)
[root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp success [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent success
Port 20048 translates to the mountd firewalld service.
Yes, that is true. And the key to,
And the result is
[egreshko@meimei ~]$ showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
Can't argue with success. :-) :-)
On Tue, Aug 27, 2019 at 11:46 PM Bob Goodwin bobgoodwin@fastmail.us wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
firewall-cmd --permanent --add-service=nfs ## for nfsv4 firewall-cmd --permanent --add-service=nfs3 ## for nfsv3, if desired firewall-cmd --permanent --add-service=rpc-bind ## for rpc/rpcbind firewall-cmd --permanent --add-service=mountd ## for "showmount ...", if desired
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:45 AM, Bob Goodwin wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:45 AM, Bob Goodwin wrote:
My NFS problems continue. The hard drive was replaced, Fedora 30 installed and NFS is configured. I think the configuration is good, I followed the instructions anyway.
Firewlld appears to be a new stumbling block and I don't know how to fix it. I looked at the Firewalld GUI and there is nothing intuitive about it. If I stop Firewlld, showmount displays the exports.
[bobg@box83 ~]$ showmount -e 192.168.2.128 clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg@box83 ~]$ showmount -e 192.168.2.128 Export list for 192.168.2.128: /home 192.168.2.0/24
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
To an extent. But recall that's Bob's network is connected to a satellite service and already protected by a firewall. I think he needs more protection against his family consuming his data quota. :-)
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko ed.greshko@greshko.com wrote:
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent
Is there a reason why you don't want to enable "111/tcp" and 200048/tcp" as "--add-service=rpc-bind" and "--add-service=mountd" would?
I could understand adding "111/tcp" only in an nfsv4-only setup because nfsv4 is "limited" to tcp, so it makes sense to try use only tcp.
[mountd's not needed on the network in an nfsv4-only setup because "showmount ..." doesn't work in such a setup]
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
To an extent. But recall that's Bob's network is connected to a satellite service and already protected by a firewall. I think he needs more protection against his family consuming his data quota. :-)
:)
The problem's that if someone does so on a laptop at home and then uses a public network...
Whether using "trusted" or adding "nfs" to "home", I suppose that the solution is to remember to change to "public" when using a public network; in the same way way that you'd want to block 111 and 2049 when doing so, whether via firewalld, iptables, nftables, or another frontend to the latter two, if they are enabled on a non-public network.
It'd be nice to have a way to associate a network and a zone and not have to remember easily-forgettable things. Given that NM and firewalld haven't done this integration, it's probably less than trivial, at least time-wise if not coding-wise.
On 8/28/19 6:06 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko ed.greshko@greshko.com wrote:
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent
Is there a reason why you don't want to enable "111/tcp" and 200048/tcp" as "--add-service=rpc-bind" and "--add-service=mountd" would?
I could understand adding "111/tcp" only in an nfsv4-only setup because nfsv4 is "limited" to tcp, so it makes sense to try use only tcp.
A couple of things. My age/background has me thinking more in "ports" than "services". I've not had any issues in a NFSv4 only environment with defining 111/udp and 20048/udp only. That too is probably an artifact of my background.
[mountd's not needed on the network in an nfsv4-only setup because "showmount ..." doesn't work in such a setup]
Not sure that is entirely true.
On the server....
[root@f30-k ~]# grep vers /etc/nfs.conf # reverse-lookup=n # vers2=n vers3=n # vers4=y # vers4.0=y # vers4.1=y # vers4.2=y
Yet on the client....
[egreshko@meimei ~]$ showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
And the current testing system has this....
[root@f30-k ~]# firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: enp0s8 sources: services: dhcpv6-client mdns nfs samba-client ssh ports: 111/udp 20048/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
And, FWIW, removing 20048/udp results in
[egreshko@meimei ~]$ showmount -e f30k rpc mount export: RPC: Timed out
But, just now, I did find a good reason for adding 111/tcp and 20048/tcp as without them I get
[egreshko@meimei ~]$ rpcinfo -p f30k f30k: RPC: Remote system error - Permission denied
And with them it is OK.
[egreshko@meimei ~]$ rpcinfo -p f30k program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 50178 status 100024 1 tcp 59315 status 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100005 2 tcp 20048 mountd 100003 4 tcp 2049 nfs
So, yes, I will need to adjust my thinking a bit and think more "services" than "ports". :-)
And remember to configure this way....
[root@f30-k ~]# firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: enp0s8 sources: services: dhcpv6-client mdns mountd nfs rpc-bind samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
On 8/28/19 6:32 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
To an extent. But recall that's Bob's network is connected to a satellite service and already protected by a firewall. I think he needs more protection against his family consuming his data quota. :-)
:)
The problem's that if someone does so on a laptop at home and then uses a public network...
I don't think that is too much of a worry.
Recall that each Wifi Connection can be assigned a Firewall Zone. The connection at home will be different than outside of the home.
Whether using "trusted" or adding "nfs" to "home", I suppose that the solution is to remember to change to "public" when using a public network; in the same way way that you'd want to block 111 and 2049 when doing so, whether via firewalld, iptables, nftables, or another frontend to the latter two, if they are enabled on a non-public network.
It'd be nice to have a way to associate a network and a zone and not have to remember easily-forgettable things. Given that NM and firewalld haven't done this integration, it's probably less than trivial, at least time-wise if not coding-wise.
It seems integration has been done with Wifi (see above) but not with wired connections.
In any event, I've never had a need or even considered running an NFS server on a laptop. :-)
On Wed, 2019-08-28 at 12:32 +0200, Tom H wrote:
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
To an extent. But recall that's Bob's network is connected to a satellite service and already protected by a firewall. I think he needs more protection against his family consuming his data quota. :-)
:)
The problem's that if someone does so on a laptop at home and then uses a public network...
Whether using "trusted" or adding "nfs" to "home", I suppose that the solution is to remember to change to "public" when using a public network; in the same way way that you'd want to block 111 and 2049 when doing so, whether via firewalld, iptables, nftables, or another frontend to the latter two, if they are enabled on a non-public network.
It'd be nice to have a way to associate a network and a zone and not have to remember easily-forgettable things. Given that NM and firewalld haven't done this integration, it's probably less than trivial, at least time-wise if not coding-wise.
I have everything set up using "public", including NFS, and this isn't even a laptop. I don't claim any special expertise in this, indeed it was largely by following Ed's advice that I got it to work. I'm afraid the firewall docs are pretty obscure for the ordinary user.
poc
On Wed, Aug 28, 2019 at 12:36 PM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 6:06 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko ed.greshko@greshko.com wrote:
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent
Is there a reason why you don't want to enable "111/tcp" and 200048/tcp" as "--add-service=rpc-bind" and "--add-service=mountd" would?
I could understand adding "111/tcp" only in an nfsv4-only setup because nfsv4 is "limited" to tcp, so it makes sense to try use only tcp.
A couple of things. My age/background has me thinking more in "ports" than "services".
Same here. I don't use firewalld or ufw, but I've learned how they work with "services" out of curiosity (and because I've worked on servers that've used them). But I prefer "ports".
I've not had any issues in a NFSv4 only environment with defining 111/udp and 20048/udp only. That too is probably an artifact of my background.
You must've had nfsv3 running too because nfsv4 is tcp-only.
[mountd's not needed on the network in an nfsv4-only setup because "showmount ..." doesn't work in such a setup]
Not sure that is entirely true.
On the server....
[root@f30-k ~]# grep vers /etc/nfs.conf # reverse-lookup=n # vers2=n vers3=n # vers4=y # vers4.0=y # vers4.1=y # vers4.2=y
Yet on the client....
[egreshko@meimei ~]$ showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
And the current testing system has this....
[root@f30-k ~]# firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: enp0s8 sources: services: dhcpv6-client mdns nfs samba-client ssh ports: 111/udp 20048/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
And, FWIW, removing 20048/udp results in
[egreshko@meimei ~]$ showmount -e f30k rpc mount export: RPC: Timed out
But, just now, I did find a good reason for adding 111/tcp and 20048/tcp as without them I get
[egreshko@meimei ~]$ rpcinfo -p f30k f30k: RPC: Remote system error - Permission denied
And with them it is OK.
[egreshko@meimei ~]$ rpcinfo -p f30k program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 50178 status 100024 1 tcp 59315 status 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100005 2 tcp 20048 mountd 100003 4 tcp 2049 nfs
So, yes, I will need to adjust my thinking a bit and think more "services" than "ports". :-)
On an nfsv4-only system with its iptables rules flushed. "showmount ..." doesn't even work locally (because it needs "rpc.mountd").
# iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
# rpcinfo -s program version(s) netid(s) service owner 100000 2,3,4 local,udp,tcp,udp6,tcp6 portmapper superuser 100003 4 tcp6,tcp nfs superuser
# cat /etc/exports /srv 192.168.0.0/24(rw,sync,no_root_squash)
# exportfs /srv 192.168.0.0/24
# cat /var/lib/nfs/etab /srv 192.168.0.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,no_pnfs,anonuid=65534,anongid=65534,sec=sys,rw,secure,no_root_squash,no_all_squash)
# showmount -e clnt_create: RPC: Program not registered
# mount 192.168.0.127:/srv /mnt
# findmnt /mnt TARGET SOURCE FSTYPE OPTIONS /mnt 192.168.0.127:/srv nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.127,local_lock=none,addr=192.168.0.127
# cat /var/lib/nfs/rmtab
# showmount -d clnt_create: RPC: Program not registered
#
And remember to configure this way....
[root@f30-k ~]# firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: enp0s8 sources: services: dhcpv6-client mdns mountd nfs rpc-bind samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Short of not changing the zones that are supplied with firewalld and adding a custom zone for enabling nfs or other network services :)
On 8/28/19 8:09 PM, Tom H wrote:
On an nfsv4-only system with its iptables rules flushed. "showmount ..." doesn't even work locally (because it needs "rpc.mountd").
# iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
# rpcinfo -s program version(s) netid(s) service owner 100000 2,3,4 local,udp,tcp,udp6,tcp6 portmapper superuser 100003 4 tcp6,tcp nfs superuser
# cat /etc/exports /srv 192.168.0.0/24(rw,sync,no_root_squash)
# exportfs /srv 192.168.0.0/24
# cat /var/lib/nfs/etab /srv 192.168.0.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,no_pnfs,anonuid=65534,anongid=65534,sec=sys,rw,secure,no_root_squash,no_all_squash)
# showmount -e clnt_create: RPC: Program not registered
# mount 192.168.0.127:/srv /mnt
# findmnt /mnt TARGET SOURCE FSTYPE OPTIONS /mnt 192.168.0.127:/srv nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.127,local_lock=none,addr=192.168.0.127
# cat /var/lib/nfs/rmtab
# showmount -d clnt_create: RPC: Program not registered
#
Interesting. I'm not going to lose any sleep over it. But I thought I had it confined to V4 with the entry in /etc/nfs.conf.
[root@meimei ~]# mount -t nfs -o nfsvers=3 f30k:/home /mnt mount.nfs: requested NFS version or transport protocol is not supported
But of course
[root@meimei ~]# mount -t nfs -o nfsvers=4 f30k:/home /mnt [root@meimei ~]# df | grep mnt f30k:/home 29110528 10145024 17463808 37% /mnt
And....
[root@meimei ~]# showmount -e f30k Export list for f30k: /home 192.168.1.0/24,2001:B030:112F:0000::/56
As well as
[root@f30-k ~]# showmount -e Export list for f30-k.greshko.com: /home 192.168.1.0/24,2001:B030:112F:0000::/56
[root@f30-k ~]# rpcinfo -s program version(s) netid(s) service owner 100000 2,3,4 local,udp,tcp,udp6,tcp6 portmapper superuser 100005 2,1 tcp6,udp6,tcp,udp mountd superuser 100024 1 tcp6,udp6,tcp,udp status 29 100003 4 tcp6,tcp nfs superuser
Shows that I have a mountd even though it should not be necessary.
Maybe I'll track down tomorrow why that is.
On Wed, Aug 28, 2019 at 12:45 PM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 6:32 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko ed.greshko@greshko.com wrote:
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko ed.greshko@greshko.com wrote:
The easiest way to resolve the issue is to place the interface on the NFS server in the "Trusted" firewall zone. The setting for that can be found in the Network Manager GUI for that interface in the "General Configuration" tab. At least that is what is shown on my KDE system.
Doesn't that essentially disable the firewall?!
To an extent. But recall that's Bob's network is connected to a satellite service and already protected by a firewall. I think he needs more protection against his family consuming his data quota. :-)
:)
The problem's that if someone does so on a laptop at home and then uses a public network...
I don't think that is too much of a worry.
Recall that each Wifi Connection can be assigned a Firewall Zone. The connection at home will be different than outside of the home.
Whether using "trusted" or adding "nfs" to "home", I suppose that the solution is to remember to change to "public" when using a public network; in the same way way that you'd want to block 111 and 2049 when doing so, whether via firewalld, iptables, nftables, or another frontend to the latter two, if they are enabled on a non-public network.
It'd be nice to have a way to associate a network and a zone and not have to remember easily-forgettable things. Given that NM and firewalld haven't done this integration, it's probably less than trivial, at least time-wise if not coding-wise.
It seems integration has been done with Wifi (see above) but not with wired connections.
Thanks. I must've missed the introduction of that feature! Stupid me...
You can now have "ZONE=" in "/etc/sysconfig/network-scripts/ifcfg-*" or "zone=" in /etc/NetworkManager/system-connections/*". Cool.
In any event, I've never had a need or even considered running an NFS server on a laptop. :-)
I used to use it when I went to a company and needed to share out some files that I needed for configuration or installation.
On 8/28/19 6:44 PM, Ed Greshko wrote:
It seems integration has been done with Wifi (see above) but not with wired connections.
On second though, there is no reason why you can't have 2 "connections" tied to the same HW with different zones. You just need to have only one "active" at any time.
On Wednesday, August 28, 2019 12:20:13 AM MST Ed Greshko wrote:
That may not be sufficient depending on the zone an interface is assigned.
Correct. See below.
firewall-cmd --add-service=nfs --zone=$ZONE firewall-cmd --add-service=nfs --zone=$ZONE --permanent
On Wednesday, August 28, 2019 3:06:50 AM MST Tom H wrote:
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko ed.greshko@greshko.com wrote:
[root@f30-k ~]# firewall-cmd --zone=home --add-port=111/udp --permanent [root@f30-k ~]# firewall-cmd --zone=home --add-port=20048/udp --permanent
Is there a reason why you don't want to enable "111/tcp" and 200048/tcp" as "--add-service=rpc-bind" and "--add-service=mountd" would?
I could understand adding "111/tcp" only in an nfsv4-only setup because nfsv4 is "limited" to tcp, so it makes sense to try use only tcp.
[mountd's not needed on the network in an nfsv4-only setup because "showmount ..." doesn't work in such a setup] _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
NFS over UDP is faster than NFS over TCP.
On Thu, Aug 29, 2019 at 5:40 AM John Harris johnmh@splentity.com wrote:
NFS over UDP is faster than NFS over TCP.
When using nfsv3, yes. But nfsv4 is tcp-only.
On Saturday, August 31, 2019 1:09:58 AM MST Tom H wrote:
On Thu, Aug 29, 2019 at 5:40 AM John Harris johnmh@splentity.com wrote:
NFS over UDP is faster than NFS over TCP.
When using nfsv3, yes. But nfsv4 is tcp-only.
nfsv4 is also slower than nfsv3, and isn't as well supported on different systems.
On Sat, 31 Aug 2019 at 22:28, John Harris johnmh@splentity.com wrote:
On Saturday, August 31, 2019 1:09:58 AM MST Tom H wrote:
On Thu, Aug 29, 2019 at 5:40 AM John Harris johnmh@splentity.com
wrote:
NFS over UDP is faster than NFS over TCP.
Until the ethernet switches get busy -- then it is common to find that UDP packets are dropped.
When using nfsv3, yes. But nfsv4 is tcp-only.
nfsv4 is also slower than nfsv3, and isn't as well supported on different systems.
These days, "different" usually means Windows. The merits of different nfs versions and UDP vs TCP depend on the workloads, network usage and topologies, etc.
nfsv3 locking uses separate processes. A years ago my work had lots of MacOS systems with nfsv3. If a client crashed (or lost power) lock files were sprinkled thru the server filesystem, causing problems for backups and other clients until the server was taken offline and the locks removed. Our workloads involved random transfers of 10-100GB data sets (numerical model output or remote sensing data sets) combined with scheduled overnight replication of a local data centre to a backup site. As a result we often had network congestion problems so UDP was not an option.
My experience with nfsv4 on linux in this environment was relatively free of problems.
On 9/1/19 8:04 PM, George N. White III wrote:
My experience with nfsv4 on linux in this environment was relatively free of problems.
+1
But, I didn't want to "argue" about it since it would be OT and like similar OT matters leads nowhere. :-)
On Sun, 2019-09-01 at 09:04 -0300, George N. White III wrote:
On Sat, 31 Aug 2019 at 22:28, John Harris johnmh@splentity.com wrote:
On Saturday, August 31, 2019 1:09:58 AM MST Tom H wrote:
On Thu, Aug 29, 2019 at 5:40 AM John Harris johnmh@splentity.com
wrote:
NFS over UDP is faster than NFS over TCP.
Until the ethernet switches get busy -- then it is common to find that UDP packets are dropped.
When using nfsv3, yes. But nfsv4 is tcp-only.
nfsv4 is also slower than nfsv3, and isn't as well supported on different systems.
These days, "different" usually means Windows. The merits of different nfs versions and UDP vs TCP depend on the workloads, network usage and topologies, etc.
nfsv3 locking uses separate processes. A years ago my work had lots of MacOS systems with nfsv3. If a client crashed (or lost power) lock files were sprinkled thru the server filesystem, causing problems for backups and other clients until the server was taken offline and the locks removed. Our workloads involved random transfers of 10-100GB data sets (numerical model output or remote sensing data sets) combined with scheduled overnight replication of a local data centre to a backup site. As a result we often had network congestion problems so UDP was not an option.
My experience with nfsv4 on linux in this environment was relatively free of problems.
Or to sum up: for some use cases, working is better than fast.
poc
-
Alexander Dalloz -
Bob Goodwin -
Ed Greshko -
George N. White III -
John Harris -
Patrick O'Callaghan -
Tom H