As you seem to have this stuff working now I am not sure what you are asking.
These network mounts show up to the standard Humax operating firmware as simulated USB drives, and they appear in the USB drive list as external drives, so you access the remote HDR-FOX via Media >> Storage (blue) >> USB. The name in the list is the name of the folder you create under My Video >> [ModSettings] >> nfs/smb.
The caveat here is that the Humax operating firmware does not recognise that a virtual USB drive exists unless it is prompted to look for one by there being a real physical USB HDD or UPD plugged in to one or both USB ports. There is a CF workaround in the form of the virtual-disk2 package - this forces the HDR to pick up any virtual USBs, but at the cost of a pop-up each boot asking what you want to do with it. It's cleaner just to have a cheapie UPD plugged in (if you don't have something plugged in already). This applies whatever form of virtual drive you are using, be that a mount with network-shares-automount, foxlink, or virtual-disk.
The shareFolder= parameter alters this behaviour. Setting shareFolder=on causes the remote share to be mapped into the My Video folder as a sub-folder, and the remote recordings are then accessed within the normal Media navigation. There are two caveats to this: first, the remote storage then gets treated by the standard operating firmware as an extension of the internal drive and can result in confusion over free space and result in a large volume of network traffic while the indexer scans it; second, I don't know whether the Humax still needs prompting to "see" it with a physical USB - I presume it does not. Personally I consider shareFolder=on to be risky, and if somebody who doesn't know about it deletes the folder it will proceed to delete the entire contents of the remote share. The same risk exists when the mount is in the USB menu, but as that is separate from the normal recorded contents there is at least a signpost that there is something different about it.
The folder= parameter is the access point in the remote device; the host= parameter specifies the remote device by IP address so there is no call to specify a host by network name in the folder= parameter. The dots in a normal IP address (four decimal numbers 0-255 separated by full stops) cannot be accommodated so are substituted by underscores in the host= parameter, and no need for leading zeros in the decimal numbers (which could lead to misoperation as it is not standard to include leading zeros). Ditto in the folder= parameter: slashes can't be used so are again substituted by underscores.
SMB is more flexible than NFS in this respect (NFS only shares below the media level), and recent updates to the samba package (which provides the server functions for SMB) allow for folder=My Video to only access the internal HDD content or folder=media to access the My Video (etc) folders and any external drives connected to that machine. Any of the entities that appear under media can be specified in the folder= line, including external drives, or any path within them, which can be used to restrict remote access (these possibilities have always been available, but previously required some custom configuration). The key point here is that any virtual drives (ie network mounts) also show up, so to avoid an infinite recursion when bilaterally sharing content between two HDR-FOXes it is necessary for one or both to share at the My Video level (both shared at media level would mean HDR1/2 could see HDR2/1 virtual USBs which contained an image of HDR1/2 which contained an image of HDR2/1...).
Installing network-shares-automount automatically installs nfs-utils (NFS client and server functions) and cifs (SMB client) as dependencies; to enable SMB sharing you also need to manually install samba (the SMB server) on the server HDR-FOX.
Content cannot be played via a network mount unless it has been decrypted. That means there is a delay after the recording completes while the DLNA indexer makes a record of it (auto-decryption cannot take place until this happens) and then auto-decryption kicks in (presuming you have it set up). Playing the recording locally before decryption is complete can bugger the process up too.
None of this is necessary if you just use the native content sharing abilities of the HDR-FOX - as long as both are connected to the same network (via WiFi dongle, Ethernet cable, HomePlug, WiFi/Ethernet adapter...) and both have Menu >> Settings >> System >> Internet Setting >> Content Share = On, each HDR-FOX will be able to play the other's content, whether StDef or HiDef, without any custom firmware or decryption etc, straight out of the box. You don't get file management, bookmarking, resume, and FF/REW abilities this way, and external drives on the remote device are not accessible, but for many people just being able to play the remote content will be sufficient (skip forward/back still works, as does the left/right scroll). This method of access is via Media >> Storage (blue) >> Network, and is available concurrently with any CF network mounts you might have set up. There is still a delay before any new recording appears in the DLNA index, and this delay is worse if there is auto-decryption and/or file relocation/renaming in the mean time.
I don't think I can explain it any clearer than that. For comments re HD-FOX as a client see two posts down.
