[network-shares-automount] package released

This is a strange one: What's this (arrowed)?

B7B76794-57CA-469B-BCE1-D3D57B1FE9A8.jpeg

5D0E09C3-FF92-45D8-82EF-C6F9BC3FF3E5.jpeg

Here's my ModSettings:

FF8743F0-634D-486B-A1CA-18C000210A2E.jpeg

Virtual disk "HDR" does not survive a reboot (it's gone now), but it isn't a one-off - I have seen it before and been waiting for it to rear its head again.

Something unusual about my config is that "HDFOX3" is the SMB share on the same unit.
 
I've discovered a strange problem. As noted above, I don't recommend shareFolder=on because the external share then gets mounted under My Video which can lead to all manner of undesirable effects (such as the HDR-FOX being unable to calculate disk stats properly, and the DLNA indexer taking a walk across the network). With the shares only being available on the USB menu, these problems go away.

What I did not expect, and have now discovered, is that on a HD-FOX this strategy does not work. Even with the shares mounted under /media as separate drives (alongside drive1), they still corrupt the stats for drive1. See thread linked from the quoted post below.

Black Hole said:
Okay, well I think I've found a reason: network-shares-automount. I don't understand it, because the shares are not mounted in media/drive1 (they are mounted in media), but removing network-shares-automount restored the proper stats, and reinstating it recreated the reporting problem. Maybe this is a bug in the HD-FOX firmware?

In the process, I tried removing flatview to no effect, and also discovered I had foxlink installed (which I don't need and had forgotten all about - but explains a mystery share!).
Click to expand...
 
I entered the various settings in the Modsettings and whilst the share appears in the webif it does not appear when pressing the blue button in storage.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    43 KB · Views: 13
I see @Drutt has disappeared from the scene. Perhaps our other gurus would have a dig and see what they can make out.

I was working on the "to be continued" stuff in my Content Sharing 101, and having a play with the folder= setting in [ModSettings]. "_" is supposed to be a proxy for "/", but I have found that although I can set folder=My Video or folder=media, folder=My Video_[FILMS] (given that there is a folder in My Video called "[FILMS]") doesn't work. Also, how is it that folder=My Video isn't folder=media_My Video (which doesn't work)?

What is the proper syntax? Is it possible to specify a complete path with the proper syntax? Is it the case that "media" and "My Video" are recognised and coded as special cases?
 
Try running it manually and see what it outputs:
Code: 
humax# killall scanmounts
humax# /mod/sbin/scanmounts
Black Hole said:
Also, how is it that folder=My Video isn't folder=media_My Video (which doesn't work)?
Click to expand...
"media/" is automatically prepended.
 
Last edited:
Well, no. Using folder=media gets you a listing containing My Video, My Music, My Photo (and any USB drives). If "media" were prefixed with "media/", that would be "media/media" - which doesn't exist.
 
I set mine to
Code: 
_media_My Video
as this ties in with what I see when I use the cli. In first entry to the cli everything is relative to /
 
Aha! Of course, obvious it might need a reference to the root (I will have another play later).

Note however that folder=media and folder=My Video work as they stand.
 
Black Hole said:
Presumably only if folder≠media
Click to expand...
It might be something like that. I recall getting confused with the initial setting up and couldn't find documentation on what it actually expected. So I gave up guessing and made sure I knew the full share directory location. It also helps the next time I create a new share as it looks obvious (to me.)
 
Thanks - but then /mod/sbin/scanmounts just sits there looking at me refusing to do anything, no return to command prompt (and I don't know how to break out other than close the webshell session). What to do?
 
That should have been "killall" not "kill". Ctrl-C should get you out (in a real terminal, not sure about Webshell).
No, I'm not running an unusual build. I don't use it at all. Just going from memory.
 
If Ctrl+C doesn't get through to the telnet session to kill the running program, try Ctrl+Z (which should display "Stopped" and a prompt) then kill %1; fg.

In the POSIX shell, you can have "background jobs" that share the console with whatever program you are actually running (the shell itself, or a "foreground job"). The Ctrl+Z interrupt suspends ("stops") the foreground job, adding it the background jobs. jobs shows what's running. The form %job-id identifies a process by its job-id for the kill command. If you have no other background jobs, kill %1 kills the job you just stopped, then fg brings it back to the foreground as a terminated process. Or instead of killing it, you can, after perhaps running some other commands, use bg to let the program resume as a background job.

Putting "&" at the end of a command makes it run directly as a background job.
 
There is a bug in tmenu which prevents Ctrl-C from working in either a telnet session or webshell when the menu system is enabled. It should be fixed in the next official CF release.
 
You must log in or register to reply here.
Back
Top