TTD Forum

Hi Guys,

I'm after some help with NASMount. I have been using this TAP for several years without issue.
My normal setup is a Debian based Open Media Vault V4 server. I have added a new HTPC to
my setup which is just a small form factor IBM thinkcentre PC running linux mint.

My linux skills are minimal but I followed a tutorial on linuxconfig.org and setup NFS server
on the thinkcentre. I successfully exported the share and the Topfield connects to it however
while it can see the shared folder it cannot see the files within it. I tried with the default
settings within NASMount.ini (-osoft,intr,tcp,rsize=65535,nolock) and also with this line empty.
No luck. I set the server share to (rw,subtree_check,insecure,no_root_squash) the same as OMV,
still no luck. I provided root access and tried chmod 777 and u+r to the shared folder but
the folder is still empty on the Topfield.

To try and eliminate any possible errors on the server I installed NFS client on an old laptop
I have running Xubuntu. It sees the share and all the files within it. I can copy / paste
/ delete on the share from the laptop. Are there any other mount options I can try in the NASMount.ini
file? I also eliminated the OMV server to see if the 2 were clashing.

Thanks,
James

Did you do only do "chmod 777 shared_folder" or "chmod -R 777 shared_folder", to go through all the files and subfolders, too?
And why are you running there linux mint, when you seem to be more accustomed to Xubuntu? I always try to minimize the diversity, to simplify known administration pathways, except if I have a very good cause for a special variant.

Hi Anthea,

I did chmod -R 777 shared_folder so all sub folders should be covered. A have a few PC's running mint. The only reason I'm running Xubuntu is that it's a light weight version. The laptop is circa 2008.

OK, so it's the other way round.

So on your server, you have the according entries in /etc/exports ? Something like "/mnt/MyData/public 192.168.1.1/24(rw,async,no_root_squash,subtree_check)"?

Is the portmapper running? You can check that with "rpcinfo -p"

Hi Anthea

Export list for 192.168.0.57:
/mnt/374db6f7-8ad4-438c-9d65-5e54c1086df4/Andrew 192.168.0.106/24

/etc/exports/
/mnt/374db6f7-8ad4-438c-9d65-5e54c1086df4/Andrew 192.168.0.106/24(rw,subtree_check,insecure,no_root_squash)

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 43310 mountd
100005 1 tcp 48825 mountd
100005 2 udp 44321 mountd
100005 2 tcp 58201 mountd
100005 3 udp 39124 mountd
100005 3 tcp 57571 mountd
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049
100003 3 udp 2049 nfs
100227 3 udp 2049
100021 1 udp 47277 nlockmgr
100021 3 udp 47277 nlockmgr
100021 4 udp 47277 nlockmgr
100021 1 tcp 35833 nlockmgr
100021 3 tcp 35833 nlockmgr
100021 4 tcp 35833 nlockmgr

All IP addresses are static

Hm, that looks normal. I'm running out of ideas...
While using the partition GUID as a mount target is good, using the GUID as a mountpoint, too, is something I personally don't like. But that's up to you.

You might try if changing "no_root_squash" to "all_squash" makes any change, or even then add the anonuid and anongid options to map the nfs requests to a specific user.

How do I find the mount point without the GUID? This maybe the issue.
If I run showmount -e on the Mint server it returns - /mnt/374db6f7-8ad4-438c-9d65-5e54c1086df4/Andrew 192.168.0.106/24

But when I do this on the OMV server (which works with NASMount) it shows - /export/Lounge 192.168.0.106/24
It doesn't even show /mnt in the path. Lounge is the shared NFS folder.

See attached pictures.

Well, one question would be: how do you access the volume inside the mint server? By that /mnt/{GUID}/ path? Or another path? Because then you could use that path for your nfs server to access.
You should see the currently used mount points by typing "mount" or "mount -l" on a shell, usually all automatically mounted partitions should also be visible in /etc/fstab

I tried another path without the GUID. I did this through the disk menu. It now displays as /mnt/sdb1/Andrew.
I then edited the exports to reflect this and restarted the NFS server and again the Topfield sees the folder but no files.

mount -l shows - /dev/sdb1 on /mnt/sdb1 type ext4 (rw,nosuid,nodev,relatime,x-gvfs-show)

nano /etc/fstab shows - /dev/sdb1 /mnt/sdb1 auto nosuid,nodev,nofail,x-gvfs-show 0 0

I can telnet into the Topfield and cd to the shared folder, even it's sub folders but ls -l or ls -la show no contents - see picture attached
It's almost like files have a hidden attribute like windows / dos -h

I have attached a second picture of a telnet session using the OMV server. It has some differences if that helps.

Today I used chown -R & chgrp -R on the mint server to match that of the OMV server.
ls -l now shows the same user / group / permissions on each servers shared folders
and NASMount remains the same. The Topfield can see the folder via mint but not the files.
OMV works perfect. I guess there's some incompatibility between Mint & NASMount?
I thought about adding the user name & password to the NASMount.ini file but it looks
like this only supported in NFS V4.

As I said previously, you could try to map the nfs login from the default anonymous user to a specific user, using the anonuid and anongid options in the nfs server. Maybe mint deactivated some anonymous user functions for security reasons?

I tried these two lines (separately) in the export file (rw,no_subtree_check,all_squash,anonuid=0,anongid=0) and (rw,no_subtree_check,all_squash,anonuid=1000,anongid=1000) 1000 is the output from the id command on the server, 0 from the Topfield
I restarted the server and NASMount after each edit but it's still same unfortunately.

Just for interest the TRF-2400 I have supports DLNA. I installed minidlna on the mint server and the Topfield
can access the same share and view / play all supported file types.

Good news Anthea,

Changing the NASMount.ini line from this Mountoptions=-o soft,intr,tcp,rsize=65535,nolock
to this Mountoptions=-o soft,intr,tcp,rsize=8192,wsize=8192,nolock
has solved the problem.

Interesting. Because according to nfs documentation, rsize and wsize should offer only a "hint" of the size to use, and server/client should negotiate what is effectively used. 8192 is near the lower end (I never understood the proposed value of 65535 anyway, as the transfered size for negotiation is rounded to a power of 2), max value is 1048576, min value 4096 (or 2048 in some cases). Effectively used sizes should be present in /proc/mounts of the client side, if someone is interested in what is used in the end. But as always, documentation doesn't have to be 100% identical to implementation....

Anyway, good that you found a solution, and posted it here, if someone has a similar issue.

The clue came from this thread when I was searching for information on minidlna,

viewtopic.php?f=134&t=39349&p=778292&hi ... na#p778292