Mount Manager Misbehaviour

MrQuade · Post by **MrQuade** » Fri Dec 30, 2016 17:26

I have noticed this before, and just put up with the mount manager being generally unreliable, but never really sat down to figure out why.

A couple of things that I nave noticed that may point to more underlying strangeness.

1) Mounts left-over after deletion
When you are in the media player and access "Locations...", you will see a list of all your mount points and bookmarks.
If you delete a network mount point, and access the media player "Locations...", the deleted mountpoint will still be listed there, but will be inaccessible.
If you perform a GUI Restart, the mount point will no longer be listed in media player "Locations...".

I thought this might be a caching issue with the media player, but perhaps it is not...
Test:
Delete network mount points and reboot Wiz.
Open MENU->Setup->Network->Network browser.
Create a network mount to another networked device.
Open MENU->Setup->Network->Mountpoints management.
Delete the newly created network mount point.
Open Media Player.
Open "Locations..."

Observe that the newly created and deleted mount point is still listed, despite the media player having been opened for the first time.

2) Mount point naming confusion.
I have a QNap NAS that offers all shares up as both CIFS and NFS, which makes this bug easier to reproduce.

When you create a CIFS mount point using the Wiz using the Network browser, the mount point configuration screen is displayed.
The mount point is given an initial name of <sharename><devicename>.
eg. QmultimediaQNAPNASSERVER

When you create a NFS moint point using the Wiz using the Network browser, the mount point configuration screen is displayed again.
However, the mount point is given an initial name of <devicename>.

That's all fair enough, it is up to the user to choose the names etc...

However, this leads to some oddities.
Test:
Use the Network browser to create a CIFS mount point to QNAPNASSERVER on share named Qmultimedia.
The default mountpoint name of QmultimediaQNAPNASSERVER is selected.
Highlight the mountpoint name field and change it to simply be QNAPNASSERVER. (ie. delete the Qmultimedia portion).
Save the mountpoint.

Now:
Use the Network browser to create a NFS mount point to QNAPNASSERVER on share named Qmultimedia.
You will now see that the mountpoint configuration screen will have instead opened the existing mount point that was created in the previous section instead of trying to create a new mount point.
Any attempt to change the settings on this mount point will result in a prompt to update the exisiting mount point when it comes time to save the mount point.
I am not sure what other confusion ensues from this, but I am sure that I have ended up with a corrupted set of AutoFS files as a result in the past.

prl · Post by **prl** » Fri Dec 30, 2016 17:51

What mount type? I can't remember FSTAB mounts ever deleting themselves properly.

MrQuade · Post by **MrQuade** » Fri Dec 30, 2016 18:38

prl wrote:What mount type? I can't remember FSTAB mounts ever deleting themselves properly.

These were just with the default AUTOFS type.

I just found it odd that a GUI restart would clear the deleted mounts out, which would suggest to me that it was an enigma2 cache problem rather than a mount/filesystem/os problem.

MrQuade · Post by **MrQuade** » Fri Dec 30, 2016 18:57

When deleting the mount point, I see the following message in /var/log/messages

Code: Select all

Dec 30 16:50:34 beyonwizt4 daemon.crit automount[8249]: key "BEYONWIZT3" not found in map source(s).
Dec 30 16:50:35 beyonwizt4 daemon.crit automount[8249]: rmdir_path: lstat of /media/autofs/BEYONWIZT3 failed

But when checking in "/media/autofs", I can see that BEYONWIZT3 has indeed been removed.

Clue? Not sure if that message is just a result of a double check the Wiz is doing, or sign of a problem.