NFS server broken (possible RPC issue)

t23 · June 2020

Using the ABAG.5 firmware on a NAS542, i installed NFS 1.3.0zypkg007 and added a share. This could not be mounted - macOS gave the error "This file server will not allow any additional users to log on", both when using v4 and v3.

So, i ssh'ed into the box, and found the problem is much stranger:

admin@542:/i-data/xxxxxxxx/.PKG/NFS/bin$ ./showmount -e
clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused)

admin@542:/i-data/xxxxxxxx/.PKG/NFS/bin$ ./rpcinfo -p
No remote programs registered.

admin@542:~$ netstat -an | grep 2049
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:2049 0.0.0.0:*

But lsof (run as root) cannot tell me what process is actually attached to port 2049 (could imagine it's a kernel module then).

rpcbind, rpc.mountd and rpc.statd are all running.

Anybody have any idea what is going on and how to fix it? Thanks in advance!

#NAS_June_2020

Kim · June 2020

I googled "This file server will not allow any additional users to log on" on the Internet and found this: https://discussions.apple.com/thread/4227674?page=1 Hope it can help.

HMMZ · June 2020

I have ran the same rpcinfo -p on a nfs server I have and got the following.

When running it on the nfs server:

$ rpcinfo -p
   program vers proto   port service
    100000    4   tcp    111 portmapper
    100000    3   tcp    111 portmapper
    100000    2   tcp    111 portmapper
    100000    4   udp    111 portmapper
    100000    3   udp    111 portmapper
    100000    2   udp    111 portmapper
    100005    1   udp 20048 mountd
    100005    1   tcp 20048 mountd
    100024    1   udp 58497 status
    100024    1   tcp 53218 status
    100005    2   udp 20048 mountd
    100005    2   tcp 20048 mountd
    100005    3   udp 20048 mountd
    100005    3   tcp 20048 mountd
    100003    3   tcp   2049 nfs
    100003    4   tcp   2049 nfs
    100227    3   tcp   2049 nfs_acl
    100003    3   udp   2049 nfs
    100003    4   udp   2049 nfs
    100227    3   udp   2049 nfs_acl
    100021    1   udp 57844 nlockmgr
    100021    3   udp 57844 nlockmgr
    100021    4   udp 57844 nlockmgr
    100021    1   tcp 37180 nlockmgr
    100021    3   tcp 37180 nlockmgr
    100021    4   tcp 37180 nlockmgr

Running the same command against the nfs server host from other host:

rpcinfo -p nfs_server_ip_address
   program vers proto   port service
    100000    4   tcp    111 portmapper
    100000    3   tcp    111 portmapper
    100000    2   tcp    111 portmapper
    100000    4   udp    111 portmapper
    100000    3   udp    111 portmapper
    100000    2   udp    111 portmapper
    100005    1   udp 20048 mountd
    100005    1   tcp 20048 mountd
    100024    1   udp 58497 status
    100024    1   tcp 53218 status
    100005    2   udp 20048 mountd
    100005    2   tcp 20048 mountd
    100005    3   udp 20048 mountd
    100005    3   tcp 20048 mountd
    100003    3   tcp   2049 nfs
    100003    4   tcp   2049 nfs
    100227    3   tcp   2049 nfs_acl
    100003    3   udp   2049 nfs
    100003    4   udp   2049 nfs
    100227    3   udp   2049 nfs_acl
    100021    1   udp 57844 nlockmgr
    100021    3   udp 57844 nlockmgr
    100021    4   udp 57844 nlockmgr
    100021    1   tcp 37180 nlockmgr
    100021    3   tcp 37180 nlockmgr
    100021    4   tcp 37180 nlockmgr

Probably as long as you don't see the same there might be services not running, like rpcbind....

All this just in case you didn't figure it out by yourself.

t23 · June 2020

It gets more hairy. After a reboot, nfs works - until you disable and reenable it from the control panel, then it reverts to the originally described behaviour.

Restarting as root on the NAS itself makes no difference.

Any other ideas?

Thanks so far, btw!

HMMZ · July 2020

Hi t23,

Facts:

- Reboot - the nfs service is running.

- Changind the state of the nfs service via web interface practically disables it and it reamins so regardless of further actions.

I think that looking through all avaiable logs would help, given the fact you can login to it via ssh and elevate to root your rights.

Identify how the service(s) are started - for example, as root, run:

a. systemctl list-unit-files

or

b. service nfsd status

If a. then continue with

systemctl list-unit-files | grep nfs

Make note of the output and use it in the following command

systemctl status service_from_above -l

This will show you the status of the service.

systemctl stop service_from_above

to stop service

systemctl start service_from_above

to start service

More info

https://www.linux.com/training-tutorials/understanding-and-using-systemd/

The goal, I understand, is to identify the correct command to start/stop the nfs service.

Otherwise, if you only want the service to run, just reboot and not act upon it from the web interface.

Mijzelf · July 2020

The NAS doesn't run systemd, so systemctl doesn't work/exist on a 542. To stop/start a package, you'll have to execute

/i-data/sysvol/.PKG/<packagename>/etc/init.d/<packagename> [startup|shutdown]

The package name in this case is NFS. so the start command is

/i-data/sysvol/.PKG/NFS/etc/init.d/NFS startup

There is no status command.

t23 · July 2020

Correct, the NAS542 uses init scripts. Stopping and starting from the nfs package's script gives the same results as disabling and reenabling from the web interface (most likely uses the same script), i.e. that all portmapper services are completely frozen and/or simply not there.

just reboot and not act upon it from the web interface

Right - not really a solution, but best workaround for sure.

Mijzelf · July 2020

Is it possible that there are connections on NFS when you restart it, causing the daemons to 'stick'?

t23 · July 2020

Is it possible that there are connections on NFS when you restart it, causing the daemons to 'stick'?

Nopes - i get your way of thinking, but that is not the case.

NFS server broken (possible RPC issue)

All Replies

Categories

Consumer Product Help Center