Lost SMB access to Humax

MymsMan

Ad detector
I have been accessing my humax disk from my Win 10 laptop with SMB for years now but recently it is refusing to connect.
Code:
The device or resource (HUMAX) is not set up to accept connections on port "The File and printer sharing (SMB)".
My initial thoughts were that SMB 1.0 support had become disabled in Windows features but it shows as enabled

I can still access the humax by webif and telnet.
File manager + on my phone can access the humax disk OK.
Samba service on humax is running and restarting it has no effect
HUMAX does appear in the list of Computers on Windows Networking display, problem occurs if you click on it.
Temporarily disabling firewall doesn't solve problem
PC can access NAS device normally.

I am (fairly) sure problem is on Windows side but am not sure what to hit next!
Any suggestions
 
Auto-discovery of network devices seems entirely random to me (Win7), but I have never seen that message. Reboot the router?
Tried rebooting PC, Humax and Router :(
PC can see humax on network, but not the disk, it can see the disks on other devices.

Another PC running Win 10 home can successfully access the Humax further pointing the finger on my main Win 10 Home laptop

I am wondering whether to try enabling NFS on my PC as an alternative to SMB,
 
Last edited:
Tried rebooting PC, Humax and Router :(
PC can see humax on network, but not the disk, it can see the disks on other devices.

Another PC running Win 10 home can successfully access the Humax further pointing the finger on my main Win 10 Home laptop
....
Some web resources seem to mention try reinstalling "files and printer sharing" although it's not always a solution.
If you have a recent restore point, try rolling back a restore point or two.
Otherwise try uninstalling recent windows updates. Check the list of updates between the two Win 10 devices to give you a clue which ones to uninstall first.
 
Did you intend for this thread type to be a Question?
I was experimenting to see what difference it made.
The main differences seem to be the ability to upvote posts and hopefully I will get to mark one as solving the problem
I think it would alter the essence of the forum, were it not for the thread defaulting to sort by date rather than sort by votes. Sorted by votes, any conversation within the thread will be almost impossible to follow and there is no opportunity to evolve a solution.
 
I think it would alter the essence of the forum, were it not for the thread defaulting to sort by date rather than sort by votes. Sorted by votes, any conversation within the thread will be almost impossible to follow and there is no opportunity to evolve a solution.
Agreed but with a standard thread it can be difficult to find the correct answer to a problem amongst all of the alternatives that have been proposed.
There are often many ways to skin a cat. With voting the most popular answers appear first, It seems to work well on sites like stackoverflow,
At least with this implementation you have the option to choose the sort order so you can get the best of both worlds
 
Agreed but with a standard thread it can be difficult to find the correct answer to a problem amongst all of the alternatives that have been proposed.
It seems to me those cases are rare anyway, and most solutions are the result of discussion and evolution. That is why I sometimes create a summary and then make sure it is referenced early in the thread.

If anybody bothers to vote.
If nobody votes, then one vote for the "best" post should bring it to the top.
 
The current recommendation seems to be to disable SMBv1 and rely on "Web Services Dynamic Discovery" to find SMB file shares.

With WSDD, to find Samba shares (especially with the antique CF version), Samba needs an auxiliary program to speak WSDD as a responder. There are several options:
  • a Python program, described and linked from the article linked above;
  • a C program from GitHub;
  • wsdd2, another C program from GitHub, based on Netgear's ReadyMedia implementation.
For Humax CF purposes, a continually running Python process is undesirably resource-intensive. I looked at wsdd2, which has the advantage of also offering a responder for MIcrosoft's LLMNR protocol, as a complement to the mDNS server in the new zeroconf package. It expects Samba to have a program that can be run as testparm -s --parameter-name="paramName" to fetch SMB configuration data (eg, "WORKGROUP"). I was able to build a running executable on-box with some plundering from glibc, but I haven't been able to see it working yet, not having a Windows 10 machine to test this on.
 
If you have a recent restore point, try rolling back a restore point or two.
Otherwise try uninstalling recent windows updates. Check the list of updates between the two Win 10 devices to give you a clue which ones to uninstall first.
Good suggestions but I found that my restore points don't go back far enough (I have now increased the space allowance)
I have backed out some updates without resolving the problem but have run into problems removing those closest to the time of the problem starting.
One seems to reinstall itself after being uninstalled, another fails to uninstall completely and another wont uninstall because it is required by the system.
 
Good suggestions but I found that my restore points don't go back far enough (I have now increased the space allowance)
I have backed out some updates without resolving the problem but have run into problems removing those closest to the time of the problem starting.
One seems to reinstall itself after being uninstalled, another fails to uninstall completely and another wont uninstall because it is required by the system.
That's a shame. The only other thing I can think of is uninstall SMB, reboot, then enable it again to see if it makes a difference.
For the second win 10 laptop (the one that still works ok for access) make the restore space larger. Perform updates multiple times and see if it get the same issue.
 
The current recommendation seems to be to disable SMBv1 and rely on "Web Services Dynamic Discovery" to find SMB file shares[/url]. ...
It now occurs to me that that would be no help at all if the server being discovered only supports SMBv1. Am I right to fear that that is still the case with the Samba package?

And a big thank-you to the Samba devs for creating a nightmare build chain. (Hint: what was wrong with tar -xf package.tar && cd package && make install?)
 
It now occurs to me that that would be no help at all if the server being discovered only supports SMBv1. Am I right to fear that that is still the case with the Samba package?
That is what I fear, discovery isn't really the problem it is the access to the remote file system that requires SMB1,

A few years ago you posted that there was too much bloat in Samba 2 for porting to Humax but I don't know what lead to that conclusion
 
Back
Top