1

Setup works (client can browse nfs over openvpn and do some work and file transfers), but something is wrong because the NFS/OpenVPN mount will fail/freeze mid-transfer and (among other things) prevent the client from restarting. issuing #mount -l during these times will just hang that terminal.

Client is arch (which now uses rpcbind), server is ubuntu server (which I think uses portmap, if this is relevant).

Fstab contains settings as follows:

10.8.0.1:/  /mnt/vpn    nfs4    _netdev,udp,bg,intr,auto  0  0

# mount -l
10.8.0.1:/ on /mnt/vpn type nfs4 (rw,relatime,vers=4.0,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,clientaddr=192.168.xxx.xxx,local_lock=none,addr=10.8.0.1,_netdev)

"bg" is so the vpn will not freeze boot when things try to start in the wrong order. "udp" is default, I believe. "intr" is supposed to allow interrupts.

Performance overall over VPN is poor/slow. I'm a bit unclear as to what else might be affecting this other than the client mount options. Appreciate any information/resource that treat nfs4 over openvpn and/or any other insight or suggestion. Thanks.

EDIT:

cat /etc/exports
/nfs4   10.8.0.0/24(rw,nohide,sync,insecure,root_squash,no_subtree_check,fsid=0)

cat /etc/default/nfs-kernel-server
# Number of servers to start up
# To disable nfsv4 on the server, specify '--no-nfs-version 4' here
RPCNFSDCOUNT=8

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
RPCMOUNTDOPTS=--manage-gids

# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=no

# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=

# Options for rpc.nfsd.
RPCNFSDOPTS=
jojo
  • 23
  • 7

1 Answers1

2

I don't think udp has been the default transport for many years, unless you are a sophisticated user with a good understanding I would suggest removing that option, or switching explicitly back to more reliable TCP.

You might also want to add the options from your /etc/exports file to your question for reference, and also any configuration options from /etc/sysconfig/nfs

I would expect to see some logging of errors into the /var/log/messages, so you might want to inspect that file for any messages and report those also.

1) http://linux.die.net/man/5/nfs - Transport Methods
"TCP is the default transport protocol used for all modern NFS implementations. It performs well in almost every conceivable network environment and provides excellent guarantees against data corruption caused by network unreliability. TCP is often a requirement for mounting a server through a network firewall. "

Tom
  • 10,886
  • 5
  • 39
  • 62
  • thanks tom. Will add those settings and hopefully some log entries to the question. I think you may be hitting on something important when you mention TCP being used for NFS. OpenVPN prefers UDP, so perhaps trying to share a NFS4 share (presumably using default TCP) inside a OpenVPN connection (using UDP) is an issue here. I have a basic understanding that these packets are different, that TCP uses some verification, and that sizes are important for packets, so will try to look at that after modifying the question and see if it moves things forward. – jojo May 26 '12 at 18:09
  • dropping the UDP flag from the mount options really seems to have cleared this up. I think what I was confused about was that using that UDP flag in the fstab was telling the client to mount the NFS share using UDP (not that it should expect the openvpn connection over UDP, which is configured elsewhere). That fstab UDP flag was apparently causing most of the hanging/freezing issues. Thanks again Tom H. – jojo May 28 '12 at 03:47