Mountpoint "Use as HDD"

[Grumpy_Geoff]

All my machines export the root directory as /root and the media directory as /media.

Then I really don't understand why your Server share is Media/hdd/movie!

But "Media" is the name of the Samba share that exports /media from the T4.

[prl]

All my machines export the root directory as /root and the media directory as /media.

Then I really don't understand why your Server share is Media/hdd/movie!

But "Media" is the name of the Samba share that exports /media from the T4.

Quite right. Ignore my post. I somehow misread the /media as /movie. Or something.

[Paul_oz53]

All my machines export the root directory as /root and the media directory as /media.

Then I really don't understand why your Server share is Media/hdd/movie!

The history to it was I used fstab to mount the Media folder. This then caused autofs to work normally on the Movie folder. I quickly learned that you cannot readily create an autofs and an fstab entry for the same folder.

I then wondered what happens if you add /hdd/movie to the fstab Server share field. The result is the fstab mount points at the movie folder and an otherwise conflicting autofs mount of the movie folder also works. I didn't expect it to work but it does.

The autofs mount is redundant of course but it has the effect of making all my shares available in the /media/autofs folder, which I occasionally use in preference to Location.

I note that Grumpy_Geoff has pointed to the Samba share as the likely reason for "Media" becoming "media".

PS I would be happy if autofs just worked for me but it doesn't in recent firmware. Fstab is a workaround that I'd rather avoid.

[Grumpy_Geoff]

ETA: when you disable "use as HDD", I think no matter how you do it, you won't get the normal HDD mount back until you reboot. I don't know of a better workaround for it than that.

Can I mount the internal drive via command line as, say, /media/i-hdd using something like -
mount -t ext4 /dev/sda1 /media/i-hdd
whilst the share is mounted as/on /media/hdd?
The reason I ask is that a timer has fired and it started to record to the share, so I can't revert just yet, but I also can't get to the internal drive.

Nup, is the answer.
root@beyonwizu4:~# mount -t ext4 /dev/sda1 /media/i-hdd
mount: mounting /dev/sda1 on /media/i-hdd failed: No such file or directory
root@beyonwizu4:~#

But -
root@beyonwizu4:~# mount -t ext4 /dev/sda1 /media/autofs
doesn't bark, and mount returns -
/dev/sda1 on /media/autofs type ext4 (rw,relatime,data=ordered)

So the internal drive's movie directory is at /media/autofs/movie
That'll do for the time being.

[prl]

root@beyonwizu4:~# mount -t ext4 /dev/sda1 /media/i-hdd
mount: mounting /dev/sda1 on /media/i-hdd failed: No such file or directory
root@beyonwizu4:~#

mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd might have been better: the mount point has to exist (the normal hotmount process that mounts /dev/sda1 on /media/hdd creates the directory as needed). But too late now.

[Grumpy_Geoff]

root@beyonwizu4:~# mount -t ext4 /dev/sda1 /media/i-hdd
mount: mounting /dev/sda1 on /media/i-hdd failed: No such file or directory
root@beyonwizu4:~#

mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd might have been better: the mount point has to exist (the normal hotmount process that mounts /dev/sda1 on /media/hdd creates the directory as needed). But too late now.

Yep, I realised that once it failed, and then thought I can just use one of the existing mountpoint directories since it was only for an hour or so whilst I streamed.

Alpha#2 passed the test as far as I'm concerned.
I've uninstalled it and I'm back to normal.

[prl]

Alpha#2 passed the test as far as I'm concerned.

Thanks.

I'm still not happy with some aspects of it - but they're long-standing bugs that have been more exposed by the testing, and which will require a lot more work to fix. The problem is that when an existing mount is modified, the code only has information about what the mount should be changed to, and nothing about what needs to be tidied up after it.

There are still a couple of commits still to add. One reduces the number of times you get asked whether you want to set a host password - the new code doesn't ask when a username/password hasn't been set and you unexpand a host, nor when you click on an NFS share.

The other refactors AutoMount.sanitizeOptions() to make bit a bit clearer what's being done, and preventing options that it adds overriding options the user has set - for example, if the user puts "nfsvers=4" in "Mount options", the system files (/etc/auto.network and /etc/fstab) get "nfsvers=4,nfsvers=3" in their options. The original code also had different sets of default options that were added depending on the "mount using" setting.

I think that I can test those well enough myself.

[sub3R]

PS I would be happy if autofs just worked for me but it doesn't in recent firmware. Fstab is a workaround that I'd rather avoid.

I think I mentioned this before Paul but I can’t remember if you tried it or not. The next time it fails try a USB install with restore settings on the Server Wiz (not required on the Client Wiz). Out of the numerous things I’ve tried this is the only thing that works for me & it works every time. I had to do it again a few weeks ago after we lost power during the recent floods.

I never used to have this problem where autofs stopped working when trying to access the Server Wiz from the Client Wiz after a power outage or after some on-line beta updates. Something broke it prior to October last year.

[MrQuade]

Quick question for those who have had issues with autofs mounts.
Have any or all of you been connecting to shares to the server's filesystem root?
I don't know if or how that would be a problem, but it struck me as a potential point of commonality.

[Paul_oz53]

Hi Sub3R,

I tried that on all 4 machines but it made no difference to me. The fstab trick though means my shares are all working.

And MrQuade,

Yes, I do share the root on my machines.

The other thing they share is their boot is slow. They all seem to stall at 34 to 36 percent. Prl suggested somewhere that this is around where autofs is loaded in the boot sequence.

Cheers Paul

[sub3R]

I don’t wish to de-rail this topic, but it sounds like you have a slightly different issue to me then Paul. It’s possible it could be related to what was broken though. I think we started getting these issues about the same time.

Mine isn’t slow to boot if it can find the shares when all shares that should be available are available. But if any aren’t available (for example if the Laptop TP500LN has been shut down) it is very slow to boot. That is normal though.

MrQuade, the following shows what I’m sharing on Wiz_U4_02 (screen capture taken of Windows Explorer on my Laptop). In this case Wiz_U4_02 was the Server that stopped working immediately after power was restored after the last power outage.

Wiz_U4_02-Win-Explorer-network_1.jpg (90.95 KiB) Viewed 2921 times

[MrQuade]

Why are you trying to connect to a Wiz via a Wiz via a Wiz?

I would really not recommend trying to navigate around your network like that.

[Grumpy_Geoff]

MrQuade, the following shows what I’m sharing on Wiz_U4_02 (screen capture taken of Windows Explorer on my Laptop). In this case Wiz_U4_02 was the Server that stopped working immediately after power was restored after the last power outage.

So you've shared out /media.
You've got a share to itself (its own /media).
That's a bit like "who's up who, and who's paying"

[sub3R]

So you've shared out /media.
You've got a share to itself (its own /media).

I remember doing that when trying multiple options to get autofs shares on the Server Wiz working again when they stopped working after an on-line f/w update or power outage – I can’t remember which. This didn’t work, but a USB update with restore settings did. Seeing how flaky Wiz autofs server/client shares have become I didn’t bother changing it back after I got it working.

But in a quick test today I disabled that share & the Client Wiz couldn’t find the Server Wiz, so it stays like that until one day when I have the time I’ll set up Wiz Server & Client shares from scratch & see what happens. But after something broke sometime last year I don’t have a lot of faith.

[prl]

On another slightly OT subject, I think that it's still being posted sometimes that pressing EXIT on the "Your network mount has been activated" or "Your network mount has been updated" popups in NetworkBrowser will call the mount operation to fail.

This isn't the case. What it does do is to drop you back into the Mounts Editor screen, and that may make it appear that the mount action was not completed, but if you check the state of the system the action will have been completed (if it could be completed).

An easy test is to deactivate/re-activate a mount (but not one with "Use as HDD replacement" enabled).

Go to the Mounts Editor screen for a mount that's not currently being accessed, switch Active to off, GREEN Save. When the "Your network mount has been updated" popup appears, press EXIT before it times out. You will be returned to the Mount Edit screen, but if you examine the mounts in /media/autofs or /media/net as appropriate, and the share should have been unmounted.

Do the same again, but set Active to on, and the share should have been remounted.

The fix is simple - it just requires some code to be removed

[MrQuade]

This isn't the case. What it does do is to drop you back into the Mounts Editor screen, and that may make it appear that the mount action was not completed, but if you check the state of the system the action will have been completed (if it could be completed).

I am not so sure about that.

I have repeatedly observed behaviour that when the exit button is pressed, the changes do not take effect. The configuration all looks ok, but when you go to access the mounts, you quickly find that the changes didnt happen.

I will have to re-test, since I haven't done this in ages, but it *was* a problem.

[Grumpy_Geoff]

I will have to re-test, since I haven't done this in ages, but it *was* a problem.

Yes, it was a problem - one had to either press OK or let the popup time out.
I don't know if this is still an issue though.

[Paul_oz53]

I will have to re-test, since I haven't done this in ages, but it *was* a problem.

Yes, it was a problem - one had to either press OK or let the popup time out.
I don't know if this is still an issue though.

+1 - but it may have changed along the way of course.

[prl]

I haven't dug back in the code to see the history of the "Your network mount has been activated" or "Your network mount has been updated" popups, but I can't replicate the problem in the current code, and I can't see how the problem could aise from looking at the code, specifically AutoMountEdit.updateConfigfinishedCB(), AutoMountEdit.Updatefinished(), AutoMountEdit.applyConfigfinishedCB() and AutoMountEdit.applyfinished(). Especially Updatefinished() and applyfinished().

Can anyone give me a replication sequence?

[Grumpy_Geoff]

Can anyone give me a replication sequence?

Not at the moment, but I'll see if I can get some time to try and find it.
From memory, and I'm not betting my leftie on this, pressing EXIT on the popup would update automounts.xml but auto.network wouldn't get the corresponding change.

[Paul_oz53]

I hope we are not wasting your time on a wild goose chase. As best I can recall it happened back in the 4.4 days.

I learned to accept a change in settings and to wait for the activated message ages ago and it has become habit. You are probably correct that it should no longer be necessary.

From the point of view of advising newbies, advising them to be patient and do one thing at a time is almost always the best path.

Whilst it may be unnecessary, I'm inclined to persist with the recommendation to press save and wait so as to minimise the risk they press multiple buttons being impatient!

[MrQuade]

I hope we are not wasting your time on a wild goose chase. As best I can recall it happened back in the 4.4 days.

It was definitely present more recently than that.

[prl]

I hope we are not wasting your time on a wild goose chase. As best I can recall it happened back in the 4.4 days.

It was definitely present more recently than that.

My recollection is that if the "Please wait..." popup was exited, the mount procedure didn't complete properly, but if the "Your network mount has been..." popup was exited nothing bad happened.

But when I looked at the history of the "Please wait..." popup, I couldn't find any time when its MessageBox didn't have enable_input = False, which makes the box impossible to exit anyway.

[prl]

Can anyone give me a replication sequence?

Not at the moment, but I'll see if I can get some time to try and find it.

Thanks.

From memory, and I'm not betting my leftie on this, pressing EXIT on the popup would update automounts.xml but auto.network wouldn't get the corresponding change.

I can't find where that might happen, but I'm happy to be shown wrong.

[Grumpy_Geoff]

From memory, and I'm not betting my leftie on this, pressing EXIT on the popup would update automounts.xml but auto.network wouldn't get the corresponding change.

I can't find where that might happen, but I'm happy to be shown wrong.

There is, or definitely was, a time when those two files got out of sync. Now, it's quite possible that I'm mis-remembering that end result with its cause.

There's three of us that know there was an issue at one point in time with using EXIT and resulting in a half-baked mount, trust us, we didn't make it up.
Like Paul, I just got into the habit of being patient - generally not one of my attributes.
I reckon the issue was even around in the early 17.5-series releases.

I won't be able to test this until Sunday, as I've a big day on the turps at the WAFL tomorrow. hic...
I can't get to either TV tonight.

[MrQuade]

I gave it a quick bash and didn't encounter the same sorts of issues with changing an existing mount, but then pressing EXIT during the countdown.

I did however, run into a couple of other bugs relating to creation of CFS and NFS mounts to the same IP/sharename combination.
(Further off-topic discussion follows).

I already had a mount configured to my NAS's "Qmultimedia" NFS share which I had given the name MediaNAS.

During my testing, I attempted to use the network browser to create a CIFS mount to the CIFS share called "Qmultimedia" on the same NAS.

Normally, CIFS mounts are given the automatic name "servername_sharename". However, when the mount option window was displayed, I was instead presented with the configuration for my existing NFS mount called "MediaNAS". All the options were as I had them set up for NFS.....so it appeared that the network browser has instead opened the existing mount, rather than try to create a new CIFS one.

I assume that this has something to do with the way the UI catalogues the shares, and it does it by a combination of servername/sharename. It should instead catalogue them by servername/sharename/protocol.

I used a different share on the same NAS for my testing. That all worked.
But as a further stress test, I then edited the new CIFS share, and changed the mountpoint to point to "Qmultimedia".

This saved the mount properly and it all worked.
I deleted the test CIFS mount.

I then noticed that the NFS mount to Qmultimedia was broken. It was still present in mountpoint manager, but was not connected.
I just had to edit it and re-save and it all came good.

But again, deleting a CIFS mount to that was pointing to the same location as a NFS mount point caused the NFS mount to fail too. (both mount points had different names on the V2 of course).

[prl]

I gave it a quick bash and didn't encounter the same sorts of issues with changing an existing mount, but then pressing EXIT during the countdown.

Thanks. I used the specific test that I described (toggling "Active") so that changes to the mount wouldn't tickle any of the other remaining bugs in NetworkBrowser.

I did however, run into a couple of other bugs relating to creation of CFS and NFS mounts to the same IP/sharename combination.
(Further off-topic discussion follows).

There are known bugs in some operations on the Mounts Editor screen (more later in the post).

I already had a mount configured to my NAS's "Qmultimedia" NFS share which I had given the name MediaNAS.

During my testing, I attempted to use the network browser to create a CIFS mount to the CIFS share called "Qmultimedia" on the same NAS.

Normally, CIFS mounts are given the automatic name "servername_sharename". However, when the mount option window was displayed, I was instead presented with the configuration for my existing NFS mount called "MediaNAS". All the options were as I had them set up for NFS.....so it appeared that the network browser has instead opened the existing mount, rather than try to create a new CIFS one.

It's hard to comment on that without knowing exactly what you did to open the Mounts Editor screen for the new mountpoint. I'd have thought that it shouldn't be a problem to create both provided they had distinct "Local share name" values, but it sounds like you ended up editing the NFS share's data to change it to a CIFS share. Doing that will trigger known bugs in NetworkBrowser.

I assume that this has something to do with the way the UI catalogues the shares, and it does it by a combination of servername/sharename. It should instead catalogue them by servername/sharename/protocol.

For simplicity, assuming "Use af HDD replacement" is off:

There is no specified "primary key" for any mount type in the automounts.xml file.

The "primary key" in the auto.network file is the autofs location (first) field. That is set to be the value of "Local share name" for the mount and must be unique within auto.network.

For fstab and enigma2 mounts, the ultimate "primary key" is the path name of the mount point. For both of them, that path name is always in the form /media/net/LocalShareName, so "Local share name" must be unique across all fstab and enigma2 mounts, but from the filesystem point of view, the same "Local file name" could be used for, say, both an autofs and an fstab mount: the first would be created in /media/autofs and the second in /media/net.

In the UI, the mounts are held in a Python dict (associative array) indexed by only "Local share name". That means that no matter what the "Mount using" or "Mount type" fields are, there can only be one share with any given "Local share name". That imposes a restriction on the names that is stricter than the file system and auto.network file but I don't think that it's a particularly onerous one. In fact it might be more confusing to the user if duplicate names were allowed in some cases, but not in others.

Where things get really strange is how changes made in the Mounts Editor are processed. It goes something like this:

Code: Select all

edit(allMountpoints[localShareNameToEdit])

for mountpointParams in allMountpoints:
	mountpointPath = getMountPath(mountpointParams)
	if mountpointParams['mountusing'] == "autofs":
		autofs("reload")
	else
		unmount(mountpointPath)
		mount(mountpointPath, mountpointParams)

The tricky bit there is that getMountpointPath() uses all of mountpointParams['sharename'] (Local share name), mountpointParams['mountusing'] (Mount using) and mountpointParams['hdd_replacement'] (Use as HDD replacement) to calculate mountpointPath, and it uses the values of those items after the edit.

This just ties the whole system of keeping the internal mountpoints table (<List of Storage Devices>, device entries in MEDIA, YELLOW Location), auto.network and fstab in sync with the internal list of mounts (as seen in MENU>Setup>Mount manager>Mountooints manager) and automounts.xml.

There are also issues with AutoMount.removeEntryFromAutofsMap() having too strict removal criteria (and otherwise buggy), and AutoMount.removeEntryFromFile() having too loose removal criteria.

I've worked out a general strategy to fix the "using the new path to unmount the old path" problem, and if I'm right about it, I should be able to speed up the save part of Mounts Editor by only updating the share being modified, rather than all of them.

Doing that will also help with the fact that AutoMount.writeMountsConfig() (run during Mounts Editor Save operation) is currently quadratic in the number of mount points when even in the current code, it could be linear.

[MrQuade]

It's hard to comment on that without knowing exactly what you did to open the Mounts Editor screen for the new mountpoint. I'd have thought that it shouldn't be a problem to create both provided they had distinct "Local share name" values, but it sounds like you ended up editing the NFS share's data to change it to a CIFS share. Doing that will trigger known bugs in NetworkBrowser.

Converting a NFS share to a NFS share was not the action I was attempting to perform. I had noticed that trying to create the new CIFS share jhad instead brought up a screen that had automatically assumed I wanted to create a NFS share. Which was odd since, in the Network browser, I had specifically selected to create a mount point to the CIFS share.

I think that bug may be in the Network Browser screen. The NFS shares are all listed before the CIFS shares.
When I tried to create a CIFS mount, the Network Browser probably iterated through a list of shares until it found one with a matching name, but since NFS was listed first, that one was selected instead of the CIFS share I actually wanted to mount.

In any case, it sounds like you have found some other little edge cases to chase out in the meantime .

[Paul_oz53]

I've worked out a general strategy to fix the "using the new path to unmount the old path" problem, and if I'm right about it, I should be able to speed up the save part of Mounts Editor by only updating the share being modified, rather than all of them.

Please do.

In the past I've relied on this characteristic to restore multiple mounts rather than loading each one by one. It would be no great loss to restore them individually.

[prl]

I think that bug may be in the Network Browser screen. The NFS shares are all listed before the CIFS shares.

That's correct.

When I tried to create a CIFS mount, the Network Browser probably iterated through a list of shares until it found one with a matching name, but since NFS was listed first, that one was selected instead of the CIFS share I actually wanted to mount.

That's pretty much it. It wasn't clear to me that there were two mounts offered by your NAS that had the same server share name (one CIFS and one NFS).

That's another nasty corner case that I hadn't noticed. The loop should match the mount type as well as the server share name in the loop that does that matching.

[Grumpy_Geoff]

I tried to trigger the issue, but failed. I mounted a CIFS share, got the "please wait" prompt, then the "updated" countdown prompt, which I exited before timeout. No issue with the mount - it was navigable.
I examined both automounts.xml and auto.network files and the contents matched.
I then re-edited the mount and changed its local share name - same test action as above, same outcome.
I repeated this same procedure with another share. Working as stated on the tin.

Only "issue" was the mount editor screen re-appearing when the mount was saved.

[prl]

Thanks, Geoff. That's exactly what I was seeing on the Beyonwiz and what looked like could be the only behaviour in the code.

I have already logged the problem about being returned to the Mounts Editor screen on EXIT from the popups. There's a similar bug with a different manifestation in Mountpoints management's YELLOW Delete mount: If you press EXIT on its "Your network mount has been removed" popup, you go back to the list of configured mounts, but the list won't have been updated and will still show the deleted mountpoint. Exiting Mountpoints management and re-entering it will show the correct mountpoints list with the deleted mountpoint no longer listed.

I have a fix for those bugs (and I'm relieved at not having to chase yet another rabbit down a hole), but I'm now scratching my head over why /etc/init.d/autofs reload sometimes doesn't correctly reload an updated auto.network.

Working on NetworkBrowser always reminds me of the old spoof (popularised by the old BSD fortune(6)) of "As I was going to St Ives": "As I was passing Project MAC"

[Grumpy_Geoff]

I have a fix for those bugs (and I'm relieved at not having to chase yet another rabbit down a hole), but I'm now scratching my head over why /etc/init.d/autofs reload sometimes doesn't correctly reload an updated auto.network.

Oh that reminds me. When I changed the local share name, I'd still see the old name present in the list of shares shown in File Commander. If there's an autofs reload happening then shouldn't this have disappeared?

[prl]

Oh that reminds me. When I changed the local share name, I'd still see the old name present in the list of shares shown in File Commander. If there's an autofs reload happening then shouldn't this have disappeared?

No, not related to the autofs reload.

Just another manifestation of the mess that's likely to be made if any of "Local share name", "Mount using" or "Use as HDD replacement" are changed on a share.

As I was passing Project MAC,
I met a Quux with seven hacks.
Every hack had seven bugs;
Every bug had seven manifestations;
Every manifestation had seven symptoms.
Symptoms, manifestations, bugs, and hacks,
How many losses at Projct MAC?

-- The Great Quux April 12, 1974

[prl]

I seem to have found the problem with autofs reload.

autofs(8):

autofs reload ... will
check the current auto.master map against the current automount
managed mounts. It will terminate those daemons or threads
(depending on autofs version) whose entries have been removed,
re-read the automount maps for entries that have changed and
start new daemons or threads for entries that have been added.

If an indirect map is modified then the change will become
effective immediately. If an indirect map uses the browse
option, the master map contains direct mount maps or the
auto.master map is modified then the autofs service control
reload action must be rerun to activate the changes.

[my emphasis]

And in auto.master(5):

[no]browse
This is an autofs specific option that is a pseudo
mount option and so is given without a leading
dash. ... This option does the same as the
deprecated --ghost option

and in /etc/auto.master:
/media/autofs /etc/auto.network --ghost



In any case, the problem is fixed by changing the autofs reload command from:
['/etc/init.d/autofs reload', 'sleep 2']
to
['/etc/init.d/autofs reload', 'sleep 2', '/etc/init.d/autofs reload', 'sleep 2']
but that only needs to be done once, when the first automount share is processed by AutoMount.CheckMountPoint().

[prl]

Here's a third NetworkBrowser alpha patch for the following bugs:
#740: Apparent failure of "Use as HDD" on autofs network mounts
#741: Some network mounts are not correctly recognised in MENU>Setup>Network
#742: More than one network mount can be set to Use as HDD replacement
#743: After disabling "Use as HDD" on autofs network mount symlink is not removed
#744: The mounted/unmounted icon sometimes doesn't update for AUTOFS network mounts
#745: Buggy sort order in Mountpoints management
#746: [NetworkBrowser] Problems with default options
#747: [NetworkBrowser] Problems with username/password requests
#748: [NetworkBrowser] Inconsistency on mount update popups
#749: [NetworkBrowser] Incorrect share sometimes selected in Network Browser

The patch includes an improved fix for #744 that will run autofs reload twice if there are any autofs mounts configured (and enabled), but only twice, no matter how many autofs mounts there are. Per the documentation, the reload appears to be required to be done in the Beyonwiz autofs setup.

#749 is the bug that MrQuade posted about recently where the qrong share could be selected for editing from Network Browser.

The issue with the mount setup being scrambled if any of "Mount using", "Local share name" or "Use as HDD replacement" is changed on an existing share is not fixed in this patch. I have started work on that, but I will do it as a separate submission from thest more minor problems. It will be a fairly large lot of changes.

The patch is in my usual form; I hope that the people who I'd normally expect to try things like this will know how to apply the patch and to uninstall it. If anyone else wants to try it, I can post more detailed instructions.

If you have either of my previous patches installed, uninstall it before installing this patch!

[Paul_oz53]

Just gave fix-networkbrowser-installer-3 a whirl on the StudyU4. Installed it but did not restart or reboot.

First I changed the autofs mount of the T3 "movie" folder share, set "Use as hdd replacement" on and saved the change. However, this had no effect. I then tried a restart but also no effect. Third, I rebooted. Again, no effect. Finally, undid the setting.

Next I tried the T3 fstab share of media/hdd/movie. Setting "Use as hdd replacement" had no immediate effect. However, when I rebooted the T3 hdd movie folder became the storage location for the U4.

I could access the T3 recordings and play them but I could not record to the T3 hdd.

The U4 hdd wasn't mounted so I telneted in and ran mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd

This resulted in it being mounted. However, it didn't show in the media player or File Commander location lists. Ran out of time so I stopped testing there.

[prl]

Just gave fix-networkbrowser-installer-3 a whirl on the StudyU4. Installed it but did not restart or reboot.

You need to at least do a UI restart for the patch to have any effect. Installing the patch isn't like installing a plugin.

[Gully]

You need to at least do a UI restart for the patch to have any effect. Installing the patch isn't like installing a plugin.

There are a few plugins that need that aren't there so I would think it should really be expected to at least do a GUI restart.

[Paul_oz53]

Just gave fix-networkbrowser-installer-3 a whirl on the StudyU4. Installed it but did not restart or reboot.

You need to at least do a UI restart for the patch to have any effect. Installing the patch isn't like installing a plugin.

Noted Peter. I thought as much but tried it anyway. When I restarted and later rebooted it still had no effect on autofs shares as noted earlier.

[Grumpy_Geoff]

My test of alpha#3.
To ensure no use of the internal drive, I disabled timeshift, disabled debug logging, stopped/disabled Samba.
Then I installed alpha#3 and rebooted.
I unmounted the internal drive to free /media/hdd mountpoint.
I went into Mountpoints managemount and enabled a CIFS share of AUTOFS type with "Use as HDD replacement" enabled.
Saved. Share was mounted.
Set off an instant recording - the "movie" directory was created and the instant recording started.
Enabled timeshifting and zapped to a new service - the "timeshift" directory was created and timeshift buffer accumulation started.
I can see /media/hdd is sym-linked to /media/autofs/{share}.
Mounted the internal drive - mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd - recordings are accessible via /media/i-hdd/movie. I streamed a recording via OWIF.
Uninstalled, rebooted.

[Grumpy_Geoff]

When I had finished testing, and after uninstalling but before rebooting, I noticed the mount table had entries for the autofs shares that use a username/password but not for any that didn't -
{sanitised}

Code: Select all

root@beyonwizu4:~# mount
//192.168.1.99/NAS-Aaron on /media/autofs/NAS_Aaron type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=loose,username={x},domain=WDMYCLOUD,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.99,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.50/Wiz-Share on /media/autofs/I5_WizShare type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=loose,username={x},domain=GRUMPY-I5-STUDY,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.50,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.99/NAS-WD on /media/autofs/NAS type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=loose,username={x},domain=WDMYCLOUD,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.99,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.50/WD_Share on /media/autofs/I5_WDShare type cifs (rw,relatime,vers=1.0,cache=loose,username={x},domain=GRUMPY-I5-STUDY,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.50,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

New mounting option/something in alpha#3?

[prl]

Just gave fix-networkbrowser-installer-3 a whirl on the StudyU4. Installed it but did not restart or reboot.

You need to at least do a UI restart for the patch to have any effect. Installing the patch isn't like installing a plugin.

Noted Peter. I thought as much but tried it anyway. When I restarted and later rebooted it still had no effect on autofs shares as noted earlier.

Thanks for the testing.

You're right about the patch being used after a reboot, but there are still potential issues about changes made when you tried the creating the share mount under the distributed firmware that may have affected the results in the second try after the reboot.

• Changing the "Use as HDD replacement" on an existing share can cause issues with the auto.network and fstab files, though I don't think that happens if you change the "HDD replacement" on an existing autofs share as you did your first trial (but that may have failed because you were using the distributed firmware).
• You mention the first share you tried as being called "movie' ("Movie"?) and the second one as being called "media/hdd/movie". That suggests that the first one was a CIFS share, and the second was an NFS share, but I'm not sure.
• On a diskful PVR, after a successful mount with "Use as HDD replacement" enabled of either an NFS or CIFS share using fstab (using autofs "HDD replacement" is known not to work on a diskful PVR) then the HDD won't be accessible. After all, you configured it to use the share as a HDD replacement.
• On a diskful PVR, after a successful mount with "Use as HDD replacement" enabled of either an NFS or CIFS share using fstab, when the "HDD replacement" is disabled (by disabling the option, making the share inactive or by removing the share), the HDD will not be remounted as /media/hdd, and the directory /media/hdd won't exist. That is a known problem, and I haven't (yet) looked at how that can be fixed most cleanly. It can be worked around by either mkdir /media/hdd && mount -t ext4 /dev/sda1 /media/hdd or a reboot (a GUI restart won't be enough). This isn't mentioned in your description of your tests, but I wanted to mention it in case you encounter it later.
• "ran mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd. This resulted in it being mounted. However, it didn't show in the media player or File Commander location lists."
  The location lists can only be updated from within the enigma2 app, and then only if the code doing the mount prods Harddisk.harddiskmanager in the right way. This bug can also be tickled, but with different symptoms, when existing mounts have any of any of "Mount using", "Local share name" or "Use as HDD replacement" is changed on an existing share.

I haven't been able to get into the state where a "HDD replacement" mount has refused to record on my V2 client/T4 server setup. I'll try to replicate it on that setup, and if I can't, I'll try on a U4 client/T3 server setup to be closer to what you've been using.

If you're inclined to try it again, then if you want to change any of "Mount using", "Local share name" or "Use as HDD replacement" on an existing share, the cleanest way to test and trigger as few of the known bugs in the patched firmware is to deactivate the existing share, and then create a new share that's the same except for the changes you want to make.

When you're done, delete the test share, re-activate the deactivated share, and then reboot. Rebooting should ensure that /dev/sda1 gets mounted as /media/hdd if it got unmounted by "Use as HDD replacement" being used on the test share.

[prl]

My test of alpha#3.

Thanks, Geoff. That all looks good.

[prl]

When I had finished testing, and after uninstalling but before rebooting, I noticed the mount table had entries for the autofs shares that use a username/password but not for any that didn't -
{sanitised}

Code: Select all

root@beyonwizu4:~# mount
//192.168.1.99/NAS-Aaron on /media/autofs/NAS_Aaron type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=loose,username={x},domain=WDMYCLOUD,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.99,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.50/Wiz-Share on /media/autofs/I5_WizShare type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=loose,username={x},domain=GRUMPY-I5-STUDY,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.50,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.99/NAS-WD on /media/autofs/NAS type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=loose,username={x},domain=WDMYCLOUD,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.99,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//192.168.1.50/WD_Share on /media/autofs/I5_WDShare type cifs (rw,relatime,vers=1.0,cache=loose,username={x},domain=GRUMPY-I5-STUDY,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.50,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

New mounting option/something in alpha#3?

Certainly not an intentional change. Though I don't see any autofs mounts at all when I run mount (V2), even after mounting a T4 CIFS share as "HDD replacement", then disabling it and rebooting.

Are there any unexpected entries in /etc/fstab?

/etc/auto.network:

Code: Select all

root@beyonwizv2:~# cat /etc/auto.network 
# automounter configuration
beyonwizt4_Movie -fstype=cifs,user=,pass=,rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.178.28/Movie
fritz_FRITZNAS -fstype=cifs,user={name},pass={passwd},rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.178.1/FRITZ.NAS/Archive/Archive/Moviesroot@beyonwizv2:~#

Listing of /media/autofs:

Code: Select all

root@beyonwizv2:~# ls /media/autofs
beyonwizt4_Movie  fritz_FRITZNAS
root@beyonwizv2:~#

Output of mount:

Code: Select all

root@beyonwizv2:~# mount
/dev/root on / type ext4 (rw,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=469348k,nr_inodes=117337,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /media type tmpfs (rw,relatime,size=64k,nr_inodes=117406)
tmpfs on /var/volatile type tmpfs (rw,relatime,size=469624k,nr_inodes=117406)
/dev/sdc1 on /media/hdd type ext4 (rw,relatime,data=ordered)
/dev/mmcblk0p3 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/etc/auto.network on /media/autofs type autofs (rw,relatime,fd=6,pgrp=2151,timeout=5,minproto=5,maxproto=5,indirect)
djmount on /media/upnp type fuse.djmount (ro,nosuid,nodev,relatime,user_id=0,group_id=0)
root@beyonwizv2:~#

[prl]

I think that MrQuade is the only one set up to test bug #749: [NetworkBrowser] Incorrect share sometimes selected in Network Browser.

[Grumpy_Geoff]

Certainly not an intentional change. Though I don't see any autofs mounts at all when I run mount (V2), even after mounting a T4 CIFS share as "HDD replacement", then disabling it and rebooting.

Are there any unexpected entries in /etc/fstab?

I had rebooted before I posted that, and as they don't now appear there's nothing to check.
Thinking about it further, forget the username/password bit as that's a red herring - there are 3 shares that weren't listed, I now realise 2 point to the NAS but can't be mounted as I had changed the minimum SMB level and their definitions don't conform, and the other was to the "Movie" share of the T4 and it was in deep standby. So mount had shown all of the available shares - appeared weird to me as I'd not seen it that way before (except when the mount is using FSTAB).

[prl]

It's still strange to me that the autofs mounts would show up in a mount listing.

[Paul_oz53]

Thanks for the testing.

You're right about the patch being used after a reboot, but there are still potential issues about changes made when you tried the creating the share mount under the distributed firmware that may have affected the results in the second try after the reboot.

• Changing the "Use as HDD replacement" on an existing share can cause issues with the auto.network and fstab files, though I don't think that happens if you change the "HDD replacement" on an existing autofs share as you did your first trial (but that may have failed because you were using the distributed firmware).
• You mention the first share you tried as being called "movie' ("Movie"?) and the second one as being called "media/hdd/movie". That suggests that the first one was a CIFS share, and the second was an NFS share, but I'm not sure.

All my shares are CIFS - I do not use NFS at all.

[*]On a diskful PVR, after a successful mount with "Use as HDD replacement" enabled of either an NFS or CIFS share using fstab (using autofs "HDD replacement" is known not to work on a diskful PVR) then the HDD won't be accessible. After all, you configured it to use the share as a HDD replacement.

Fstab certainly works but perhaps I didn't grasp that autofs will only work if the PVR has no disk internally to start with. Mine does have a disk which I didn't bother to disconnect. Prefer not to open the box if I can avoid it.

[*]On a diskful PVR, after a successful mount with "Use as HDD replacement" enabled of either an NFS or CIFS share using fstab, when the "HDD replacement" is disabled (by disabling the option, making the share inactive or by removing the share), the HDD will not be remounted as /media/hdd, and the directory /media/hdd won't exist. That is a known problem, and I haven't (yet) looked at how that can be fixed most cleanly. It can be worked around by either mkdir /media/hdd && mount -t ext4 /dev/sda1 /media/hdd or a reboot (a GUI restart won't be enough). This isn't mentioned in your description of your tests, but I wanted to mention it in case you encounter it later.

Yes, I found this out the hard way! After a reboot the internal drive did get remounted.

[*]"ran mkdir /media/i-hdd && mount -t ext4 /dev/sda1 /media/i-hdd. This resulted in it being mounted. However, it didn't show in the media player or File Commander location lists."
The location lists can only be updated from within the enigma2 app, and then only if the code doing the mount prods Harddisk.harddiskmanager in the right way. This bug can also be tickled, but with different symptoms, when existing mounts have any of any of "Mount using", "Local share name" or "Use as HDD replacement" is changed on an existing share.
[/list]

As noted below, I got this to work today.

I haven't been able to get into the state where a "HDD replacement" mount has refused to record on my V2 client/T4 server setup. I'll try to replicate it on that setup, and if I can't, I'll try on a U4 client/T3 server setup to be closer to what you've been using.

If you're inclined to try it again, then if you want to change any of "Mount using", "Local share name" or "Use as HDD replacement" on an existing share, the cleanest way to test and trigger as few of the known bugs in the patched firmware is to deactivate the existing share, and then create a new share that's the same except for the changes you want to make.

When you're done, delete the test share, re-activate the deactivated share, and then reboot. Rebooting should ensure that /dev/sda1 gets mounted as /media/hdd if it got unmounted by "Use as HDD replacement" being used on the test share.

Thanks prl. We crossed paths I fear. While you were writing this I was doing some more testing so I haven't followed your script. I decided I needed to have a clean U4 machine in base configuration to test to eliminate customisations as an issue.

I reflashed by usb to 20210119 and did not restore settings. After setting up terrestrial and the network connection I installed version 3 of the fix and rebooted again with no shares at all - a virgin testbed. The boot was very fast and did not pause at 34-36% as it had been doing previously - I expected this to be the case.

I then created an autofs - CIFS share of the lounge U4 Media folder using the Network Browser and ticked Use as hdd replacement. This did not work. The folder did not mount at all and was not accessible. As you say above, it wasn't expected to work.

I added an autofs - CIFS share of the lounge U4 Movie folder which also failed to mount. This is my long-standing problem with autofs: it refuses to work for me on my networked U4s and T4 but is ok on the T3. The network is wired ethernet with router assigned IP addresses by MAC address. The U4s and T4 can see the Windows PCs fine using autofs though.

I deleted these shares and rebooted. I then created an fstab - CIFS share of the lounge U4 Movie folder and ticked Use as hdd replacement. This worked. Note that vers=2.1 was deleted in all my tests.

I was able to record to the Lounge U4 hdd in the movie folder created for the Study U4 within the Lounge U4 movie folder.

After running the mount... command via telnet I was also able to locate the i-hdd folder and access recordings therein.

I then disabled Use as hdd replacement and rebooted. The internal hdd returned to normal function. I was the able to restore settings and return the Study U4 to its customised state.

I am at wits end with autofs. It just doesn't work normally in recent iterations of the firmware on my machines. Fortunately, fstab does work. As I swapped to the U4 as the host I can't say why the T3 as host would not record but could playback.