NFS mounting issues

[Viktor Jaep]

I also tried Victa Jaep new backupmon.sh that implemented those changes

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Still error bad file descriptor.
Reverted back to unchanged backupmon.sh

Can you try this:

mkdir -m 755 -p "/var/lib/nfs"
modprobe nfs nfsv3
portmap

...then try your mount statement

 

[pedeb04]

Can you try this:

mkdir -m 755 -p "/var/lib/nfs"
modprobe nfs nfsv3
portmap

...then try your mount statement

Still the same, bad file descriptor.

server /etc/exports
I've tried
/srv/nfsshared 192.168.50.0/24(rw,root_squash,anonuid=1000,anongid=1000)
/srv/nfsshared 192.168.50.0/24(rw,no_root_squash,anonuid=1000,anongid=1000)
/srv/nfsshared 192.168.50.0/24(rw,root_squash)

 

[Jeffrey Young]

What are the permissions on your server? Try setting 777 as a tes (allow everything for everyone).

 

[Jeffrey Young]

Also make sure your NAS allows nvfv3 connections.

 

[Jeffrey Young]

I just remembered.... I believe I read in the changelog for 1006 firmware that NFS is broken. I am away from home now for a few days, I will check later. I am running 388 codebase on my ax86u pro.

 

[pedeb04]

Changed permissions to 777 on server /srv/sfsshared, nfsv3 is enabled by default on server. no change.

 

[bennor]

I just remembered.... I believe I read in the changelog for 1006 firmware that NFS is broken. I am away from home now for a few days, I will check later. I am running 388 codebase on my ax86u pro.

The 3006.102.x Asus-Merlin Change Log only mentions NFS not supported on WiFi 7 devices.

3006.102.1 (28-Jun-2024)
...
- NOTE: Wifi 7 devices don't support NFS (issue with new
toolchain), QoS classification page (issue with
TrendMicro BWDPI) or Wifi Radar (not updated by
Broadcom).

 

[Jeffrey Young]

The 3006.102.x Asus-Merlin Change Log only mentions NFS not supported on WiFi 7 devices.

Ok. Thanks @bennor I knew I read something about NFS not working on something. You saved me looking it up.

@pedeb04 , I am afraid that I am out of ideas. Bad file descriptor is usually a sign that a permission issue exists. Mind me asking what you are using as a NAS?

Using the modified steps from above, I am able to mount an NFS share that I have set up as a test on a Ubuntu 22.04 bare metal machine. I'll send you my export contents later today when home. I do use a couple other options, but I doubt they would make a difference.

 

[pedeb04]

I am using Ubuntu server 24.04 and my Desktop is Ubuntu 24.04
When I mount the nfs share on the server from the desktop I notice the nfsvers=4.2

peter@nuc:~$ nfsstat -m
/mnt/nfs from 192.168.50.46:/srv/nfsshared
 Flags:    rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.50.175,local_lock=none,addr=192.168.50.46

If I try to mount using nfsvers=3 from the desktop but it times out.
I've tried to find a way to change/configure the server nfs export share to nfs3 with no luck so far. I'm thinking this is where the issue is.

 

[Jeffrey Young]

I am using Ubuntu server 24.04 and my Desktop is Ubuntu 24.04
When I mount the nfs share on the server from the desktop I notice the nfsvers=4.2

peter@nuc:~$ nfsstat -m
/mnt/nfs from 192.168.50.46:/srv/nfsshared
 Flags:    rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.50.175,local_lock=none,addr=192.168.50.46

If I try to mount using nfsvers=3 from the desktop but it times out.
I've tried to find a way to change/configure the server nfs export share to nfs3 with no luck so far. I'm thinking this is where the issue is.

I figured it was going to be a server/permission issue. Not a lost exercise as we learned that some additional steps to get NFS working on the router with some models may be required.

Give this a try -

On your server, add the insecure option to your export line.

NFSv3 uses port 2049 (I think) primarily and port 111 is used by portmap. NFVv4 consolidated the port usage to just port 2049. In secure mode, NFSv4 prevents any port usage below port 1024. To allow NFSv3, you need to tell the server to allow port 111, which is the insecure option. This is a very rough description (getting ready to head out for the week - best I could google for now).

 

[Jeffrey Young]

Also, if you are using a firewall on your server, try turning it off. Your firewall may be blocking Port 111.

 

[pedeb04]

Disabling the firewall on the server allowed me to mount the nfs share on the server.
Port 2049 is allowed already (when I setup the nfs share) so I allowed port 111 tcp & udp on the server, but that didn't work. Adding insecure in the export options made no difference.
I'm thinking nfsv3 might be using other ports as well.
Thanks for all your help.

 

[pedeb04]

peter@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
    100024    1   udp  44569  status
    100024    1   tcp  54107  status
    100005    1   udp  37810  mountd
    100005    1   tcp  46089  mountd
    100005    2   udp  50602  mountd
    100005    2   tcp  46693  mountd
    100005    3   udp  49132  mountd
    100005    3   tcp  43291  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100021    1   udp  40761  nlockmgr
    100021    3   udp  40761  nlockmgr
    100021    4   udp  40761  nlockmgr
    100021    1   tcp  34469  nlockmgr
    100021    3   tcp  34469  nlockmgr
    100021    4   tcp  34469  nlockmgr

There seems to be a lot of ports used for remote procedure calls on the server!!!

 

[Jeffrey Young]

Progress. Ok, mountd appears to use a random port on the server, so lets lock it down so you can make a reliable firewall rule.

Edit the /e t c/nfs.conf file and find the lines;

[mountd]
#port=0

Uncomment the port line and change the port to some high number. Does not matter what the number is, just not that the port is not already used. say

[mountd]
port=13025

Save and close the editor. Restart the nfs server (systemctl restart nfs-kernel-server)

Then open up the port. I am assuming you are using ufw

ufw allow from 192.168.50.0/24 to any port 13025
ufw allow from 192.168.50.0/24 to any port 111        # this rule should already to presant
ufw allow from 192.168.50.0/24 to any port 2049        # this rule should already be presant

NFSv4 is simpler here as v4 consolidates all communications into port 2049. It's v3 that is being a pain.

I did read that the following ufw command should also allow all three ports, but I am skeptical as mountd seems to randomize the port unless it is locked down as above.

ufw allow from 192.168.50.0/24 to any port nfs

I can see this command working for NFSv4, but not NFSv3. You can try it if you wish.

 

[pedeb04]

Yes, I had read that about mountd and before I posted yesterday I did

• edit the /etc/nfs.conf and set a port under [mountd]
• restarted the nfs-server
• and updated the ufw

But it still didn't work, so I changed it back to the default #port=0

Today, I set port=9024 for mountd and restarted the nfs-server and I noticed that when I ran rpcinfo -m that the nlockmgr ports are random/changing.

peter@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
    100024    1   udp  54575  status
    100024    1   tcp  46379  status
    100005    1   udp   9024  mountd
    100005    1   tcp   9024  mountd
    100005    2   udp   9024  mountd
    100005    2   tcp   9024  mountd
    100005    3   udp   9024  mountd
    100005    3   tcp   9024  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100021    1   udp  35609  nlockmgr
    100021    3   udp  35609  nlockmgr
    100021    4   udp  35609  nlockmgr
    100021    1   tcp  37071  nlockmgr
    100021    3   tcp  37071  nlockmgr
    100021    4   tcp  37071  nlockmgr

So I thought I might have to set ports under [lockd] and [statd] as well. But before doing that I openned up the ports for status and nlockmgr in ufw.

peter@server:/$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
Samba                      ALLOW       Anywhere                 
22/tcp                     ALLOW       Anywhere                 
2049                       ALLOW       192.168.50.0/24           
111                        ALLOW       198.168.50.0/24           
9024                       ALLOW       192.168.50.0/24           
54575                      ALLOW       192.168.50.0/24           
46379                      ALLOW       192.168.50.0/24           
35609                      ALLOW       192.168.50.0/24           
37071                      ALLOW       192.168.50.0/24           
Samba (v6)                 ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

But this didn't work either.
Below is /etc/nfs.conf

# This is a general configuration for the
# NFS daemons and tools
#
[general]
pipefs-directory=/run/rpc_pipefs
#
[nfsrahead]
# nfs=15000
# nfs4=16000
#
[exports]
# rootdir=/export
#
[exportfs]
# debug=0
#
[gssd]
# verbosity=0
# rpc-verbosity=0
# use-memcache=0
# use-machine-creds=1
# use-gss-proxy=0
# avoid-dns=1
# limit-to-legacy-enctypes=0
# context-timeout=0
# rpc-timeout=5
# keytab-file=/etc/krb5.keytab
# cred-cache-directory=
# preferred-realm=
# set-home=1
# upcall-timeout=30
# cancel-timed-out-upcalls=0
#
[lockd]
# port=0
# udp-port=0
#
[exportd]
# debug="all|auth|call|general|parse"
# manage-gids=n
# state-directory-path=/var/lib/nfs
# threads=1
# cache-use-ipaddr=n
# ttl=1800
[mountd]
# debug="all|auth|call|general|parse"
# manage-gids=y
# descriptors=0
port=9024
# threads=1
# reverse-lookup=n
# state-directory-path=/var/lib/nfs
# ha-callout=
# cache-use-ipaddr=n
# ttl=1800
#
[nfsdcld]
# debug=0
# storagedir=/var/lib/nfs/nfsdcld
#
[nfsdcltrack]
# debug=0
# storagedir=/var/lib/nfs/nfsdcltrack
#
[nfsd]
# debug=0
# threads=8
# host=
# port=0
# grace-time=90
# lease-time=90
# udp=n
# tcp=y
# vers3=y
# vers4=y
# vers4.0=y
# vers4.1=y
# vers4.2=y
# rdma=n
# rdma-port=20049

[statd]
# debug=0
# port=0
# outgoing-port=0
# name=
# state-directory-path=/var/lib/nfs/statd
# ha-callout=
# no-notify=0
#
[sm-notify]
# debug=0
# force=0
# retry-time=900
# outgoing-port=
# outgoing-addr=
# lift-grace=y
#
[svcgssd]
# principal=

Let me know if you can see something I am missing otherwise I'm going to stop trying.

 

[Jeffrey Young]

Sorry. Just don't know enough about NFS. I did read that the software engineers keep changing the config behavior between versions. Previously the config was done in /e t c/defaults/NFS on Ubuntu 20.04, thenconfig lives in /e t c/NFS.config in 22.04. maybe 24.04 is different yet again.

At least you know it is a firewall issue. I don't know what all runs on your server or if you have any internet facing services on it, so the decision on rather a firewall is required is really up to your own risk tolerance level.

Another thing you could try, if you run entware. The entware repo has an NFSv4 client package. Have never used it, nor have I need for it, but if a firewall is a must for you and you really need NFS on the router, you could give the entware NFS client a shot.

Otherwise, thanks for the conversation. It has been a learning experience for me and I have added a bunch of new notes to my NFS file for Merlin.

 

[pedeb04]