DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 1st May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Post OpenBSD NFS help

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?

Last edited by hanzer; 2nd May 2016 at 01:15 AM. Reason: To get rid of that pink face icon
Reply With Quote
  #2   (View Single Post)  
Old 1st May 2016
Oko Oko is offline
Banned
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,088
Default

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.

Last edited by Oko; 2nd May 2016 at 01:12 AM.
Reply With Quote
  #3   (View Single Post)  
Old 2nd May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Thumbs up Solved

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.
Reply With Quote
  #4   (View Single Post)  
Old 2nd May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Default

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

Last edited by hanzer; 2nd May 2016 at 04:59 AM. Reason: added top data
Reply With Quote
  #5   (View Single Post)  
Old 2nd May 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,242
Default

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.
Reply With Quote
  #6   (View Single Post)  
Old 2nd May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Default

Quote:
Originally Posted by jggimi View Post
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?
Reply With Quote
  #7   (View Single Post)  
Old 2nd May 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,242
Default

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.
Reply With Quote
  #8   (View Single Post)  
Old 2nd May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Default

Quote:
Originally Posted by jggimi View Post
[...] 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).

Last edited by hanzer; 2nd May 2016 at 03:33 PM. Reason: added BTW
Reply With Quote
  #9   (View Single Post)  
Old 2nd May 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,242
Default

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.
Reply With Quote
Old 2nd May 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
cybernetic organism
 
Join Date: Oct 2013
Location: {cyborg, psyborg, sciborg} [non-]space
Posts: 180
Default

Quote:
Originally Posted by jggimi View Post
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.
Reply With Quote
Old 2nd May 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,242
Default

If you believe this is the case, I recommend two steps:
  1. Upgrade to a -current snapshot. This may solve one or both problems for you.
  2. 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
Reply With Quote
Old 2nd May 2016
Oko Oko is offline
Banned
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,088
Default

Quote:
Originally Posted by hanzer View Post
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 03:39 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick