4:45 p.m.
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
4:51 p.m.
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(a)box83 ~]$ showmount -e 192.168.2.128
clnt_create: RPC: Unable to receive
"systemctl stop firewalld" on the server:
[bobg(a)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.
--
If simple questions can be answered with a simple google query then why are there so many
of them?
5:05 p.m.
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(a)box83 ~]$ showmount -e 192.168.2.128
> clnt_create: RPC: Unable to receive
>
> "systemctl stop firewalld" on the server:
>
> [bobg(a)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.
--
Bob Goodwin - Zuni, Virginia, USA
http://www.qrz.com/db/W2BOD
box83 FEDORA-30/64bit LINUX XFCE Fastmail POP3
5:17 p.m.
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
--
Bob Goodwin - Zuni, Virginia, USA
http://www.qrz.com/db/W2BOD
box83 FEDORA-30/64bit LINUX XFCE Fastmail POP3
5:47 p.m.
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
--
If simple questions can be answered with a simple google query then why are there so many
of them?
5:53 p.m.
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.
--
Bob Goodwin - Zuni, Virginia, USA
http://www.qrz.com/db/W2BOD
box83 FEDORA-30/64bit LINUX XFCE Fastmail POP3
1:52 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
--
John M. Harris, Jr. <johnmh(a)splentity.com>
Splentity
https://splentity.com/
2:20 a.m.
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
--
If simple questions can be answered with a simple google query then why are there so many
of them?
3:27 a.m.
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
3:40 a.m.
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. :-) :-)
--
If simple questions can be answered with a simple google query then why are there so many
of them?
4:42 a.m.
On Tue, Aug 27, 2019 at 11:46 PM Bob Goodwin <bobgoodwin(a)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
4:44 a.m.
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko <ed.greshko(a)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?!
4:54 a.m.
On 8/28/19 5:44 PM, Tom H wrote:
On Tue, Aug 27, 2019 at 11:52 PM Ed Greshko
<ed.greshko(a)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. :-)
--
If simple questions can be answered with a simple google query then why are there so many
of them?
5:06 a.m.
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko <ed.greshko(a)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]
5:32 a.m.
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko <ed.greshko(a)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(a)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.
5:35 a.m.
On 8/28/19 6:06 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 9:21 AM Ed Greshko
<ed.greshko(a)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:
--
If simple questions can be answered with a simple google query then why are there so many
of them?
5:44 a.m.
On 8/28/19 6:32 PM, Tom H wrote:
On Wed, Aug 28, 2019 at 11:55 AM Ed Greshko
<ed.greshko(a)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(a)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. :-)
--
If simple questions can be answered with a simple google query then why are there so many
of them?
5:49 a.m.
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(a)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(a)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
7:09 a.m.
On Wed, Aug 28, 2019 at 12:36 PM Ed Greshko <ed.greshko(a)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(a)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 :)
7:29 a.m.
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.
--
If simple questions can be answered with a simple google query then why are there so many
of them?
7:37 a.m.
On Wed, Aug 28, 2019 at 12:45 PM Ed Greshko <ed.greshko(a)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(a)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(a)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.
7:44 a.m.
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.
--
If simple questions can be answered with a simple google query then why are there so many
of them?
10:23 p.m.
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
--
John M. Harris, Jr. <johnmh(a)splentity.com>
Splentity
https://splentity.com/
10:40 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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.
--
John M. Harris, Jr. <johnmh(a)splentity.com>
Splentity
https://splentity.com/
8:27 p.m.
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(a)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.
--
John M. Harris, Jr. <johnmh(a)splentity.com>
Splentity
https://splentity.com/
7:04 a.m.
On Sat, 31 Aug 2019 at 22:28, John Harris <johnmh(a)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(a)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.
--
George N. White III
7:18 a.m.
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. :-)
--
If simple questions can be answered with a simple google query then why are there so many
of them?
8:50 a.m.
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(a)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(a)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
1705
days inactive
1710
days old
29 comments
7 participants
participants (7)
-
Alexander Dalloz -
Bob Goodwin -
Ed Greshko -
George N. White III -
John Harris -
Patrick O'Callaghan -
Tom H