Some network mounts are not correctly recognised in MENU>Setup>Network

[prl]

Network mounts of CIFS shares that designate a Server share that contains a relative path to a directory under a mountpoint (e.g. MYSHARE/MyMedia), and all network mounts of NFS shares, fail to be matched with their entries in /etc/enigma2/automounts.xml. This is because of incorrect and inconsistent comparisons between the share name returned from the server by smbclient and showmounts, and the <sharedir/> attribute for the mount in automounts.xml.

This means that where the comparisons fail, the mount won’t be shown as mounted in MENU>Setup>Network>Network browser (though it will be correctly shown as mounted in MENU>Setup>Network>Mount manager>Mountpoints management, which uses a different test on whether the mountpoint is mounted), and if in either Network browser or Mountpoints management, you try to edit the mountpoint the mountpoint edit screen will open with the defaults for the mount, not the current values for the mount.

Replication

Describing the full replication path is complicated, but there should be enough in the description to allow replication. Changing the Local share name from its default should be enough to see the issue with the edit screen showing the default values rather than the current configuration.

[prl]

Set component.

[Peter Urbanec]

I’m not sure if this is directly relevant to this bug, but please be aware that there are some differences between NFSv3 and NFSv4. If there are changes to the way mounts are handled, it would be good if you could test against both NFSv3 and NFSv4 servers, just in case…

[prl]

The only changes the fix makes is to how the strings returned by showmounts -e <server> are stored in, and compared with, the corresponding values in automounts.xml.

I only have NFS servers on the Beyonwiz. It looks as though the V2 has a v4 NFS server, but the default mounts ask to connect using v3. Do any of the older models only have v3 servers?

I intended to release an alpha patch for people to play with before I did a PR anyway. I’ll ask specifically about v3 compatibility.

[prl]

I’m wondering now whether you’re referring to AutoMount.sanitizeOptions(). It certainly doesn’t handle NFS versions very well. If I add nfsvers=4 to the options in an NFS mount config screen, the auto.network entry gets nfsvers=4,nfsvers=3. I haven’t been able to find out what effect that has, but it doesn’t look good.

sanitizeOptions() has the usual sort of implicit assumptions about user input that plagued (and continue to plague) the rest of NetworkBrowser.

Anyway, my fix for this bug doesn’t change sanitizeOptions(), so it should do nothing to affect the issues it has.

[Peter Urbanec]

As you noted, the code is messy to say the least. The fact that it sometimes works for some of the people is almost accidental.

My original comment was to point out that NFSv4 export semantics are different to those of NFSv3. When I migrated my Linux servers and workstations, this change necessitated non-trivial changes to my autofs configuration on those systems. It also required deleting and setting up NFS mounts on the Beyonwiz systems. I though that while you are making changes here, you should be aware that you may see differences between NFS implementations.

[prl]

I’ve started reworking sanitizeOptions() and I’m finding that it’s actually simpler than it looks - once some seemingly pointless differences between the code for autofs, fstab and enigma2 mount types are ignored.

I’m also looking at the documentation for mount.nfs and mount.cifs to see exactly how the allowed options vary between mount types.

Do you remember what sorts of things needed to be changed when you re-did the mounts to mount the NFSv4 servers on the Beyonwiz?

[prl]

Perhaps an easier question to answer would be: what mount options do you use to mount shares from an NFSv4 server?

[Peter Urbanec]

I’ve got the following two alternatives working on separate systems:

-fstype=nfs,nfsvers=4,hard,dev,suid,ac
-fstype=nfs,nfsvers=3,ro,nolock,tcp,rsize=8192,wsize=8192,timeo=14,soft

In terms of exports, the NFSv3 config used to export only the /exported path and that was the only thing mounted on clients. A move to NFSv4 required exporting multiple paths: /exported, /exported/TV, /exported/Music, each with distinct fsid assigned.

On the NFSv4 client, I’ve got an auto-expanding autofs map for this that contains * &:/ and everything Just Works(TM).

On the NFSv3 client, /etc/auto.master contains

/media/autofs  /etc/auto.network  --ghost

and /etc/auto.network has

NAS -fstype=nfs,ro,nolock,tcp,nfsvers=3,rsize=8192,wsize=8192,timeo=14,soft 192.168.42.254:/exported

this mounts the /exported path on /media/autofs/NAS and as you descend the directory hierarchy, NFS automatically mounts the subvolumes as required. I have not attempted to only mount the individual subvolumes, such as /exported/TV. I imagine that some users may want to do that.

For reference:

root@beyonwizt4:~# showmount -e 192.168.42.254
Export list for 192.168.42.254:
/exported/Movies 192.168.42.0/24
/exported/Music  192.168.42.0/24
/exported/TV     192.168.42.0/24
/exported        192.168.42.0/24

‌

[prl]

The new code for sanitizeOptions() should handle the options you want in a more-or-less sensible manner, at least avoiding things like nfsvers=3,…,nfsvers=4 and ro,…,rw.
This is what the new code will do with those options:
NFSv3 options

setup screen: ro,nolock,tcp
auto.network: -fstype=nfs,ro,nolock,tcp,nfsvers=3,rsize=8192,wsize=8192,timeo=14,soft 192.168.178.28:/media/hdd/movie
auto.network peteru: -fstype=nfs,ro,nolock,tcp,nfsvers=3,rsize=8192,wsize=8192,timeo=14,soft 192.168.42.254:/exported

NFSv4 options

setup screen: nfsvers=4,hard,dev,suid,ac
auto.network: -fstype=nfs,nfsvers=4,hard,dev,suid,ac,rw,rsize=8192,wsize=8192,proto=tcp,timeo=14 192.168.178.28:/media/hdd/movie

I’ll do a bit more experimenting and try to replicate your setup with a T4 as the “NAS”. I’ve never used auto-expanding maps. I have a feeling that it may not work well (and I’m not sure where the mount options would go).