NFS problem

[Robert Rojek]

I found that I have problem with mounting NFS share from DNS-320 with Alt-F to my Debian server. I don't understand what I am missing there but from my Debian server I executed 

root@debian:/home/robert# mount 192.168.1.5:/mnt/md0 /mnt/           

mount.nfs: Connection timed out

in system.log of DNS I can see

dns-320-fff382 daemon.notice rpc.mountd[1961]: authenticated mount request from 192.168.1.14:903 for /mnt/md0 (/mnt/md0)

[root@dns-320-fff382]# cat /etc/exports

/mnt/md0 *(rw,no_subtree_check,)

I tried many other options, including insecure or anonuid+anonguid, I was changing ownership of files from root to nobody, etc. and I never could mount any NFS share neither from that server nor from AndroidTV always can get authenticated mount - what I am doing wrong? 

Samba shares are fine and accessible in that drive. 

[Rolf Pedersen]

From my 320 Alt-F:

[root@DNS-320]# cat /etc/exports
/mnt/sda2
192.168.1.0/24(rw,no_root_squash,no_subtree_check,anonuid=99,anongid=98,insecure)

From my Mageia 7 Linux PC:

[rolf@x570i ~]$ grep 320a /etc/fstab
# mount 320/sda2 at 320a
192.168.1.186:/mnt/sda2/Public/RW /mnt/320a nfs defaults,nofail 0 0
[rolf@x570i ~]$ mount | grep 320a
192.168.1.186:/mnt/sda2/Public/RW on /mnt/320a type nfs
(rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.186,mountvers=3,mountport=47338,mountproto=udp,local_lock=none,addr=192.168.1.186)
[rolf@x570i ~]$

I sometimes have to thrash about blindly and frantically to get my NAS
mounts working, so this is just for example...
ISTR that "mountvers=3" switch to be one of the less obvious switches to
try but I mostly just hammer til it works. ;)

[Robert Rojek]

the culprit here was btrfs file system which I had configured on my old disk. I decided to upgrade my disks and at this occasion it was chosen ext4. After that no problems at all with mounting NFS shares on that Debian mentioned above neither on Android TV.

[João Cardoso]

On Thursday, March 4, 2021 at 9:39:22 PM UTC verw...@gmail.com wrote:

the culprit here was btrfs file system

Yes, I confirmed that.

The issue is that fsid=num|root|uuid must be specified as an NFS export option for btrfs. An arbitrary small integer must be supplied as 'num'.

Using the fs uuid, as reported by 'blkid' or 'btrfs filesystem show', does not works for btrfs, but works for other filesystems, (ext4 at least).

Don't know who the real culprit is, nfs-utils, btrfs-progs, or the kernel itself.

Thanks for reporting back.