Foxsat HDR crosslinking problem.


Novice Member

This is my first post, so apologies if my netiquette isn't up to scratch.

I have two Foxsat HDRs, both with separate fixed IP addresses, different names, and both with Raydon's latest firmware (v. 4.1.3). I am trying to crosslink them, but am having a problem which I can't see mentioned anywhere else on this or other forums:

When I try to mount the virtual usb drive on the other machine, I get this error:

Sat Nov 21 11:56:14 GMT 2015 : Found Gadget on : sda1
Sat Nov 21 11:56:14 GMT 2015 : Pinging Host
Sat Nov 21 11:56:16 GMT 2015 : 3 packets transmitted, 3 packets received, 0% packet loss
Sat Nov 21 11:56:16 GMT 2015 : Ping of host successfull .... mapping drive
Sat Nov 21 11:56:16 GMT 2015 : Making mount point directory /media/sda1/Bedroom
Sat Nov 21 11:56:16 GMT 2015 : Mounting // onto /media/sda1/Bedroom
Sat Nov 21 11:56:16 GMT 2015 : ERROR Mounting // onto /media/sda1
Sat Nov 21 11:56:16 GMT 2015 : Mount command returns => mount: Mounting // on /media/sda1/Bedroom failed: Host is down
Sat Nov 21 11:56:16 GMT 2015 : Finished mounting all mount points

But, when I then look in the sending machine's media listing and switch from HDD to USB, I find the mount point directory has been created on the sending machine, and not the intended target.

I'm hoping someone may be able to help.

To clarify, the Nasmount log above is running on the first Foxsat (named Lounge, and with an IP address of, and is trying to mount a virtual drive on the second Foxsat (named Bedroom, with an IP address of

I did have a successful connection previously running on both machines connecting to a 2Tb NAS, but deleted both shares in case that was the issue affecting the crosslinking, but it made no difference. I have rebooted both Foxsats after each settings change, and also stopped and restarted Samba on both machines, all to no avail.


Well-known Member
To clarify, the Nasmount log above is running on the first Foxsat (named Lounge, and with an IP address of, and is trying to mount a virtual drive on the second Foxsat (named Bedroom, with an IP address of

That's not quite what the log shows. It shows that you are trying to mount the "Video" share on and to "map it" to a folder called "Bedroom" on the virtual USB drive on the box where the log was generated (

Some basic questions:

  • On is Samba running? This can be verified by looking in the "Services" section of the Web Interface
  • Have you made an edits to the samba configuration file on either of the boxes?
  • What username/password have you configured in NASMount for this mount point. Obviously you don't have to post the full password
  • Can you sucessfully connect to \\\Video from e.g. a Windows machine (map a drive in Windows explorer) using the same username/password as above?
  • Does the same thing happen the other way round? If you try to mount // from does that work?


Novice Member
Hi Adrian,

Many thanks for responding.

Samba is running on both machines. I even stopped the service and restarted it to be sure, and rebooted both Foxsats. Both show Samba as Autostart ON, and service ON.

I haven't made any edits to samba configuration file on either box, at least knowingly. I have altered the System Settings hostnames to Lounge and Bedroom which I assume affects Samba?

I have tried usernames of root and HumaxFTP with the passwords r*** and 0*** respectively.

No, I can't connect to \\\Video from a Windows 7 machine. I get "the remote device or resource won't accept the connection". Both boxes are shown in the Network, but I can't access either. I don't reach the point of having to enter a username or password.

Exactly the same applies if I try to access the Lounge box (

Hope that all helps!




Well-known Member
Hmmm. Bit of a mystery.

Can suggest a few things to try - really just looking for more information.

1. We could go old school and try an manual mount in Windows. Might give more information. In a Windows command prompt (DOS window) type the following command:

net use * \\\Video /user:root <root passwd>

Where <root passwd> is the password for the root user. Maybe there will be more information in the error provided.

2. You could ensure that the Samba password is what you think it is for the "root" user by telneting onto the Humax and issueing the command "smbpasswd -a root". You will be prompted to enter and confirm the password. Might make a difference.

3. If all else fails you could uninstall and reinstall Samba via the Package Management page of the Web Interface. Personally I would suggest a reboot inbetween the uninstall and reinstall.

If I'm honest I'm not sure what the above will yeild but it's worth having a shot for diagnostic purposes.


Novice Member
Hi Adrian,

1. net use returns the error message "System error 53 has occurred. The network path was not found".

2. I Telnetted into both boxes and changed both passwords successfully. No error message from either machine.

3. I removed Samba from both boxes, rebooted, then reinstalled Samba. However, both boxes saved the samb.conf file, and did not replace that on reinstallation. I tried reinstalling 4.1.3 on both boxes, but again existing configuration files were retained. Understandably, nothing has changed, and I suspect the problem lies within the Samba configuration file(s). Can I somehow get back to a fresh install? I can't work out how to delete the existing .conf files without being able to access the drives from Windows. I do have an old laptop with Ubuntu on it, but have no experience using Linux.

Hope that is of some use!




Well-known Member
I may have figured this one out.

I think it has to do with the samba configuration file shipped with the samba package and your somewhat unusual network addresses. The Samba configuration file includes a line which tells it which TCP/IP addresses or subnets to allow connections from. Since you are using an unusual subnet, connections won't be allowed to the shares. You have two options:

1. Remove the relevant line in the samba configuration file. Advantage : easy edit. Disadvantage : connections will be allowed from ANY subnet potentially opening up the shares to unwanted outsiders

2. Update the relevant line in the samba configuration file. Advantage : more secure. Disadvantage : harder edit.

I would suggest option 2. You can do this by FTPing the file off the system, editing it (e.g. in Notepad++ NOT notepad) and FTPing it back.

Or you can use the somewhat clunky "vi" editor that comes with busybox in the custom firmware. I'll have a stab at talking you through that.

Telnet onto one of your boxes, then type:

vi /opt/etc/smb.conf

This will bring up the configuration file in the "vi" editor.

Use the cursor keys to move down to line 16 which begins "hosts allow = 10. 172.16. " etc

Use the cursor keys to move the cursor to the "1" of the "10." just after the "=" sign.

Hit the "i" key to begin an insert

Type "199.199.199. " (without the quotes but including the trailing space)

The line should now look like this ... "hosts allow = 199.199.199. 10. 172.16. " etc.

Hit the "Escape" key to exit insert mode

Type ":wq" to write the file back and quit the editor

You should now be back to the command prompt in the telnet window. If you want to check you've edited it correctly type:

cat /opt/etc/smb.conf | grep 'hosts allow'

You should see the line you've edited including your edit.

Stop and start the samba service (or reboot the box) and try again. The shares on that box should now be accessible to the other Foxsat and the Windows PC.

Good luck!!


Novice Member
Absolutely brilliant Adrian.

I followed your option 2 instructions carefully, rebooted the box, and hey presto! the share appeared in the Windows network.

Repeated the steps on the second box with the same result, then successfully cross-mounted the boxes. All is working as it should.

Thanks very much for all your help. I wouldn't have got here without you.




Well-known Member
The subnet address you are using is a routable address issued to Rangenet internet services in Minnesota. It is normal to use a non-routable address on a private network and never a routable address that inbound traffic will go elsewhere.

The latest video from AVForums

Are the TCL MiniLED TVs better than OLED? TCL Interview with Marek Maciejewski | AVForums Podcast
Subscribe to our YouTube channel
Support AVForums with Patreon

Top Bottom