OpenBSD NFS help

hanzer · #1 **(View Single Post)** 1st May 2016

This is goofy but I can't seem to get NFS to work between two OpenBSD machines on a LAN. This is the configuration:

Code:

Wireless ISP                                     Wireless ISP
    ^                                                ^
 (ral0)-minerva-(re0) --->  LAN <-- (re0)-galileo7-(rtwn0)

minerva runs dhcpd, unbound, and NAT's Internet traffic from the LAN. galileo7 currently has rtwn0 disabled. Other than galileo7's wireless problems (probably due to hardware specific firmware/driver issues), the network seems to be working as I expect it to. This is the NFS situation:
minerva: /etc/exports

Code:

/home/hanzer/nfs -alldirs -rw -mapall=hanzer:hanzer -network=192.168.0 -mask=255.255.255.0

And from either machine, $ rpcinfo -p minerva returns:

Code:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    789  mountd
    100005    3   udp    789  mountd
    100005    1   tcp    656  mountd
    100005    3   tcp    656  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

But, hanzer@galileo7:$ doas mount_nfs minerva:/home/hanzer/nfs /home/hanzer/minerva returns:

Code:

mount_nfs: can't access /home/hanzer/nfs: Permission denied

Maybe some firewall blockage? (I'm a PF lightweight and halfwit)
minerva: /etc/pf.conf

Code:

int_if="{ re0 }"
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
                   172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
                   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
                   203.0.113.0/24 }
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
block in quick on egress from <martians> to any
block all
pass out quick inet
pass in on $int_if inet

galileo7: /etc/pf.conf

Code:

set skip on lo
int_if="{ re0 }"
set block-policy drop
match in all scrub (no-df random-id max-mss 1440)
block all
pass out quick inet
pass in on $int_if inet

Any ideas or suggested experiments?

Oko · #2 **(View Single Post)** 1st May 2016

Error you are getting is typical for two situations:

1. /etc/exports not properly configure so the directory you are trying to NFS-mount is
either not exported or not exported on that particular network.
2. You are have some privileges wrong (typically trying to export and use something as a root) so you need what Linux people call "Insecure Mount". I have seen this on older Apple MACs NFS clients.

That being said why do you have PF running on your LAN zone? While theoretically possible that you push NFS through specific ports (I do that at work) that is just a cheap hack which IIRC was never available on the OpenBSD version of NFS server. For the purposes of debugging you don't want to have firewall while trying to configure NFS server.

hanzer · #3 **(View Single Post)** 2nd May 2016

Apparently, while -ro is a valid option in /etc/exports (for read only), -rw is not the way to specify read/write access. I guess the only way to specify read/write access is to say nothing

Anyway, with this change on minerva: /etc/exports

Code:

/home/hanzer/nfs -alldirs -mapall=hanzer:hanzer -network=192.168.0 -mask=255.255.255.0

NFS now works as expected.

hanzer · #4 **(View Single Post)** 2nd May 2016

Is NFS unstable or easily confused?

After a few hours, the NFS client machine can no longer $ ls ~/nfs (ls hangs). The machine isn't hung, the ssh/tmux connection is fine, the network is up, the server seems fine, it's just not NFS'ing data.

Remember the good ole days when everything just worked? (I don't

)

$ top shows this for the client machine processes that are trying to access the NFS shared directory:

Code:

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
32294 hanzer    -1    0  352M  390M idle      nfsrcvl  71:08  0.00% python2.7
11286 hanzer    -1    0   86M  111M idle      nfsrcvl   7:06  0.00% python2.7
14091 hanzer    -5    0   88M  114M idle      getblk    6:39  0.00% python2.7
30302 hanzer    -1    0  488K  348K idle      nfsrcvl   0:00  0.00% ls
 2011 hanzer    -1    0  180K  200K idle      nfsrcvl   0:00  0.00% df

jggimi · #5 **(View Single Post)** 2nd May 2016

The FAQ describes several status / statistic tools, but I've never found them very useful as "diagnostic" aids: showmount(8) and nfsstat(1).

I'm using NFS, and it usually works well. But when there are occasional client hangs, the only "reset" I've been able to find that works is a reboot of the client. Unlike the server, which is a set of userland programs, the client is a kernel service.

hanzer · #6 **(View Single Post)** 2nd May 2016

Quote:

Originally Posted by jggimi

I'm using NFS, and it usually works well. But when there are occasional client hangs, the only "reset" I've been able to find that works is a reboot of the client. Unlike the server, which is a set of userland programs, the client is a kernel service.

Occasional client hangs? Holy crap! NFS is in the kernel and it isn't reliable? How does that happen?

Would net/samba work any better on low resource machines?

jggimi · #7 **(View Single Post)** 2nd May 2016

1. Breathe.

2. Calm down.

3. Relax.

The occasional problems that I get come from laptop network changes. Operational issues that are caused by me: how I have things provisioned and how I use them.

My NFS mounts are over a private vlan(4) which requires wired Ethernet. When I unplug and switch to WiFi, that vlan is no longer active. NFS stops operating. If I have forgotten to dismount before disconnecting .... mounts are still in place. But not operational.

If in this state I try to do any I/O to an NFS-mounted device, the I/O doesn't complete. If it's a utility such as df(1), it won't complete unless I remember to add the -l option. If I forget, Ctrl-C will stop the utility.

If I plug the wired Ethernet back in, and reconnect the vlan(), NFS operations usually resume. They are UDP by default, and NFS has its own error recovery.

---

There have been rare occasions where something I have done precludes the resumption of NFS client connectivity. Applications doing I/O hung and could not be terminated. In those rare instances, reboot of the client has been necessary. Each time, it was something I did.

hanzer · #8 **(View Single Post)** 2nd May 2016

Quote:

Originally Posted by jggimi

[...] If it's a utility such as df(1), it won't complete unless I remember to add the -l option. If I forget, Ctrl-C will stop the utility.

Interesting, Ctrl-C wouldn't break the ls(1) or df(1) hangs in my case. Maybe there is something peculiar with this hardware that is causing the odd software behavior. During the week or two that it's been running OpenBSD, it has had other unresolved problems.

BTW - nor would $ kill -9 break the hung ls(1) or df(1).

jggimi · #9 **(View Single Post)** 2nd May 2016

Are you attempting to use NFS via WiFi? My general guidance on NFS over WiFi is don't. More specifically:

Never connect an NFS server to a network with WiFi.
Avoid clients over WiFi whenever possible.

If you absolutely cannot use wired networking, consider TCP rather than UDP.

hanzer · #10 **(View Single Post)** 2nd May 2016

Quote:

Originally Posted by jggimi

Are you attempting to use NFS via WiFi?

NFS is over a wired network (re0 to re0, described above).

If NFS works reliably [for others] and rtwn works reliably [for others] then I suspect this particular hardware has [silent] OpenBSD compatibility issues.

jggimi · #11 **(View Single Post)** 2nd May 2016

If you believe this is the case, I recommend two steps:

Upgrade to a -current snapshot. This may solve one or both problems for you.
If the problems continue, post informal problem reports to the misc@ mailing list, requesting assistance. Don't assume there is a bug, or a compatibility problem. There may be one or more provisioning issues that this community has not identified from your posts.

The misc@ mailing list is a much larger community than this one. There are thousands of subscribers and active participants. And while it isn't particularly newbie-friendly, it is newbie accepting if the newbie has done their homework.

http://www.openbsd.org/mail.html

Oko · #12 **(View Single Post)** 2nd May 2016

Quote:

Originally Posted by hanzer

Occasional client hangs? Holy crap! NFS is in the kernel and it isn't reliable? How does that happen?

Would net/samba work any better on low resource machines?

OpenBSD NFS client might be quite slow without any tuning

https://marc.info/?l=openbsd-misc&m=146128769228676&w=2

but I can attest that it is rock stable. I have machines at work running OpenBSD amd64 which we use as ssh gateways with up-time 7-8 months (essentially from one upgrade to another). Users home directories are of course mounted as NFS. Their actual home directories are scattered over several different FreeNAS servers.

As you could see from the above thread at home I run DFly NAS server and my data is mounted as NFS to my OpenBSD desktop.

I can't speak of OpenBSD NFS server implementation. OpenBSD file system support was always Achilles Tendon and I personally don't know anybody who uses OpenBSD as a storage OS for large deployments. I had high hopes when Walter Neto start posting WAPBL patches (important for embedded devices and core partitions) on tech@openbsd
https://marc.info/?l=openbsd-misc&m=145917025913348&w=2

and Tkusumi of DFly even promised to bring HAMMER1 to OpenBSD

https://www.dragonflydigest.com/2016/04/11/17932.html

In that tread I also suggested that somebody from OpenBSD camp should definitely have a look at that NFSv3 DFly server implementation.

IMHO considering Samba on UNIX is a non-starter.