The network-shares-automount package generates a [Shares] folder in My Video which we are warned must never be deleted. Is it possible to move this folder to the VirtualUSB so that it's safely out of the way? At present it appears just above listed recordings in My Video, so there is quite a risk of accidentally deleting it when meaning to delete the top-most of these recordings.
[Shares] folder produced by the network-shares-automount package
- Thread starter MalcolmC
- Start date
I already had shareFolder=off, but wasn't sure I had rebooted with the Network drive off. I did this. The "shared filesystem" appears under media (as they always did) but the [Shares] folder is still in My Video. It's this [Shares] folder that we must "never delete" that I am concerned about. I do not want to delete it -- just the opposite, I want to avoid accidentally deleting it.
Black Hole
May contain traces of nut
It all depends what you want to do. The reason for having the [Shares] folder is so you can navigate the mounted network drive straight from MEDIA without having to select Storage >> USB. It's a convenience thing, but has the consequence that if deleted by accident (or unaware of the consequences) the delete operation will then systematically empty the remote storage.
If you don't need the convenience (and personally I don't recommend it for several reasons), and are quite happy to go via MEDIA >> Storage, then you will find the external mounts listed as virtual drives in the USB list. Provided shareFolder=off, [Shares] is a remnant which can be deleted without issue.
If you don't need the convenience (and personally I don't recommend it for several reasons), and are quite happy to go via MEDIA >> Storage, then you will find the external mounts listed as virtual drives in the USB list. Provided shareFolder=off, [Shares] is a remnant which can be deleted without issue.
Last edited:
Aha, thanks. The [Shares] folder must be present because I once tried out the shareFolder=on option, but then went back to "off".
MymsMan
Ad detector
Yes the package creates the folder when needed but doesn't clean up when it is no longer needed
If you make sure the the network drive is not active before deleting the folder there will be no danger of anything being deleted from the network drive
Last.To.Know
Member
Not sure if it's bad form to revive someone else's thread but here goes.
Somewhat recklessly, about 10 minutes ago I deleted the [Shares] Do not delete! folder.
It was empty.
What have I done?
Which is to ask, have I done anything bad and what should I be looking for?
(Yes, BH, living up to my username once again)
I also have a [ModSettings]folder which I haven't touched.
Somewhat recklessly, about 10 minutes ago I deleted the [Shares] Do not delete! folder.
It was empty.
What have I done?
Which is to ask, have I done anything bad and what should I be looking for?
(Yes, BH, living up to my username once again)
I also have a [ModSettings]folder which I haven't touched.
Black Hole
May contain traces of nut
If there was really nothing in it, you've (probably) not done any harm. I imagine the folder will be recreated automatically by the network-shares-automount (NSA) package (if it's installed).
What should have been in it is any remote shares currently connected through NSA (if shareFolder=on), and if there had been any your action would have proceeded to delete the content on those remote servers.
The clue is in the phrase "do not delete", which should probably read "do not delete unless you've taken measures to ensure this will not have any adverse consequences"... but that's a bit of a mouthful.
Two ways to make the [Shares] folder safe to delete:
Again, the [ModSettings] folder is part of the NSA installation. Only delete it if you no longer have NSA installed (or want to corrupt it).
What should have been in it is any remote shares currently connected through NSA (if shareFolder=on), and if there had been any your action would have proceeded to delete the content on those remote servers.
The clue is in the phrase "do not delete", which should probably read "do not delete unless you've taken measures to ensure this will not have any adverse consequences"... but that's a bit of a mouthful.
Two ways to make the [Shares] folder safe to delete:
- In [ModSettings], in all instances of setting "shareFolder" set it to OFF; or
- Uninstall the NSA package.
Again, the [ModSettings] folder is part of the NSA installation. Only delete it if you no longer have NSA installed (or want to corrupt it).
Last to bother reading information, you mean. In any case, you're not the only one. Somebody did it twice (and deleted their server as a result, twice)!
Last.To.Know
Member
It is.
One instance, set to ON.
For future reference, how do I set it to OFF?
For now, I think I'll uninstall network-shares-automount to be on the safe side and because I rarely used it.
Black Hole
May contain traces of nut
The point of the [ModSettings] folder is to make the share parameters accessible for editing via the SUI - so you can simply go in and edit the strings using the on-screen media browser options, or alternatively the media browser in the WebIF.
IMO, [Shares] is such a potential pain that I leave it turned off. Remote shares are then still accessible as virtual USB drives (much safer). [Shares] are for people who must have all their content in one place, or are too lazy to use Media >> Storage >> USB.
Last.To.Know
Member
I share your opinion.
Thank you for your wise words.
Thank you for your wise words.
Last.To.Know
Member
aaarrrggghhh!
I am now getting a 500 Internal Server Error in Web-IF, which I can't help but think is not a coincidence.
I have powered down and switched off completely using the rear switch.
Powered up again with the same error.
Any help gratefully received.
[Edit] As you were.
I followed the advice in this thread which fixed the problem.
Specifically, post #9 from MymsMan and post #11 from prpr, so thank you to those two helpers.
For future users needing to fix a 500 Internal Server Error in Web-IF, I
I am now getting a 500 Internal Server Error in Web-IF, which I can't help but think is not a coincidence.
I have powered down and switched off completely using the rear switch.
Powered up again with the same error.
Any help gratefully received.
[Edit] As you were.
I followed the advice in this thread which fixed the problem.
Specifically, post #9 from MymsMan and post #11 from prpr, so thank you to those two helpers.
For future users needing to fix a 500 Internal Server Error in Web-IF, I
- Used PuTTY to telnet into the HDR-FOX T2
- Entered the PIN (usually 0000)
- Entered cli to get the command line
- Pasted cat /var/log/webif-error.log
- Which brought back /mod/bin/jimsh: can't load library 'libutil.so.0'
- Pasted opkg install --force-reinstall libutil
Last edited:
Last.To.Know
Member
It was on all pages.
Log is empty...
Log is empty...
Last.To.Know
Member
2023-10-19 16:28:44: (server.c.1464) server started (lighttpd/1.4.53)
Oh, wasn't quite expecting that.
All packages seem to have re-installed happily.
Code:
Name Installed Autostart Running
---- --------- --------- -------
betaftpd Yes Yes Yes
cifs No No No
cron Yes Yes Yes
epg Yes Yes Yes
lighttpd Yes Yes Yes
nfs No No No
recmon Yes Yes Yes
samba No No NoMymsMan
Ad detector
So does that mean webif is working again or not?
So are you actually using any network share since all of CIFS, SMB and NFS seems to be stopped from auto starting?
Which file sharing protocol are/were you using?
I don't think any of them are needed for basic webif usage
prpr
Well-Known Member
He said yesterday (in an edit) that it was all working after reinstalling libutil. We're still no clearer to working out the cause.
They're not starting because they're not installed.
So.
MymsMan
Ad detector
Ah I had missed the post update and only saw post #14 so thought webif-error.log was empty when problem still existed!
Last.To.Know
Member
I did think it was odd...
But I thought you wanted these readings to help with future diagnostics.
As I said in my edit of post #12, you did help, so thank you for that.