3

As part of a startup a rescuecd uses busybox to mount a nfs share with data, but during the nfs share mount, busybox (version v1.18.2 from systemrescuecd) always fails to mount the nfs share. And i do not find the reason why, because when using an alternative it works

mount -o intr,nolock,rsize=1024,wsize=1024 192.168.0.3:/rescue /boot 
mount: mounting 192.168.0.3:/rescue on /boot failed: Connection timeout

# On the serverside 
>> authenticated mount request from 192.168.0.69:642 for /rescue

But here comes the mystery, when i use the following command on the same busybox commandline the nfs mount works (and the server message does NOT appear).

mount.nfs 192.168.0.3:/rescue /boot -o intr,nolock,rsize=1024,wsize=1024

# This works and it is mounted.

What is the difference, who can i make the "normal" mount work on busybox (which is a symlink to busybox)

Otherwise i have to modify the systemrescuecd to make it work. but maybe there is a nfs server tweak just to accept whatever busybox tries to accomplish.

EDIT: Found out that the mount command is succesful, when the "tcp" option is added.

mount -o intr,nolock,rsize=1024,wsize=1024,tcp 192.168.0.3:/rescue /boot

So the question is more now, why does the mount fail with the "udp" option

mount -o intr,nolock,rsize=1024,wsize=1024,udp 192.168.0.3:/rescue /boot

I am lost here.

2
  • Is your iptables configuration identical in both situations? Jan 1, 2018 at 20:39
  • yes it is the very same commandline. Busybox drops after faiure into the commandlline. First command (original one) fails, the second succeeds. I have a further data point, added above
    – Mandragor
    Jan 2, 2018 at 8:15

1 Answer 1

1

You have to enable the nfs server to listen on udp port. This is option -u (see also: man nfsd).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .