My setup

There is a box containing an NSLU2 (aka a "slug") controlling a church heating system and running Slugos (which is essentially Linux - the IOT tends to be running somewhat ancient Linuxen). I access it from home using ssh and NFSv3 (because slugos does not seem to like NFSv4).

One of the perils of NFSv3 is that the firewall in the router at the far end requires fixed port numbers for mountd and statd. For purposes of experimentation, I have set up an identical "slug" on my LAN at home, where the following behaviour was observed.

The Problem

I have got it to the state where rpcinfo -p gives:

program vers proto port service 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100021 1 udp 39590 nlockmgr 100021 3 udp 39590 nlockmgr 100021 4 udp 39590 nlockmgr 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 tcp 52524 nlockmgr 100021 3 tcp 52524 nlockmgr 100021 4 tcp 52524 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100024 1 udp 7791 status 100024 1 tcp 7791 status

Now I start mountd with mountd -f /etc/exports -p 7792 which adds the following

100005    1   udp   7792  mountd
100005    1   tcp   7792  mountd
100005    2   udp   7792  mountd
100005    2   tcp   7792  mountd
100005    3   udp   7792  mountd
100005    3   tcp   7792  mountd

which is exactly what I want. Now to put that in the appropriate /etc/init.d file, which is customarily done by calling

start-stop-daemon --start --exec /usr/sbin/mountd -- "-f /etc/exports -p 7792"

But that gives me

100005    1   tcp  47725  mountd
100005    2   udp  47909  mountd
100005    2   tcp  47725  mountd
100005    3   udp  47909  mountd
100005    3   tcp  47725  mountd

so it has ignored the -p 7792.

I could doubtless hack my way around it, but how can it be that start-stop-daemon behaves in such a crazy way?

1 Answer 1


At least if this is Debian/Ubuntu start-stop-daemon, you shouldn't be quoting the arguments like that.

start-stop-daemon --start --exec /usr/sbin/mountd -- -f /etc/exports -p 7792

ought to work. (When you quote it, its being sent to mountd as one command-line argument, not the four it should be.)

  • Actually, it was the old Linux's start-stop-daemon. But this is still run under a shell, and I should have known better. The quotes should not have been there (I was just trying to follow other lines in the same script which ended in "$@"). All now working, but a messy setup in the router for NFSv3, so I still need to find why NFSv4 would not work - so I may be back for that hater. Sep 25, 2019 at 20:43
  • @CharlesLindsey "$@" is a weird bit of shell syntax; it's the same as writing "$1" "$2" "$3" ... (in other words, it passes the parameters exactly as they were received, without doing any additional joining or whitespace splitting). (Just in case you're still wondering about the other lines)
    – derobert
    Sep 25, 2019 at 20:53
  • @CharlesLindsey BTW, as for NFSv4, I'd suggest the first thing to do is confirm it supports NFSv4. Considering how old of a kernel that is. You might also consider, longer-term, if you can port to something more modern, like a Raspberry Pi...
    – derobert
    Sep 25, 2019 at 20:56
  • Yes, NFS4 has been supported several versions before that kernel, and it will indeed mount slug:/, but it fails to mount slug:/usr/local (which is in a different partition), even though it mounts it in NFS3 (and once it has done that, it will then mount it using NFS4). I suspect something is going wrong in the dentry cache, but debugging that will not be easy. Sep 27, 2019 at 18:15

You must log in to answer this question.

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