Hi!
We are developing a product that is logging data on a Linux-embedded board (SOM module), and we need to access and copy these data from a C++ software running on a Windows 10/11 laptop (customers laptop). For that, we have set up a Samba (SMB) server on the embedded Linux and we are trying to access it from Windows, but we are running into many troubles.
The Linux board is connected to the Windows laptop using RNDIS over USB, creating a network adapter on the Windows laptop. The Linux board is running a DHCP server and the Samba server is exposing the network share containing the data that we need to copy. The share is accessed using \192.168.41.1\share from the Windows laptop.
1) We wanted to have system that is as simple as possible, i.e. with a simple public share. But some Windows versions (Enterprise) or group policies seem to be blocking the access to public shares, making this impossible. This is sad and we cannot change that as our customers are also big companies with strict group policies. Is there any way/plan to allow that on "local" networks in the future?
2) In some cases, Windows still ask for credentials when connecting on a public share (with no password!), and then fails to connect. Is this a known issue?
So, to try to work-around these 2 first issues, we added a trivial user/password to the Samba share.
3) Windows is now asking for credentials when accessing the network share. It is quite laggy, taking 10-30s to ask for credentials. Usually it work. But in some cases, it still fails to connect even though the credentials are entered correctly. Sniffing the traffic using WireShark shows that Windows is trying to connect with the "Windows User" instead of the username and password provided in the credential dialog !!! Only a reboot seem to fix that issue. Is this a known bug?
4) As we are also using a C++ software to copy the data (automatically), we used WinAPI to log into the share, using the following code:
QString logsPath("//192.168.41.1/share");
NETRESOURCEW nr;
memset(&nr, 0, sizeof(NETRESOURCE));
// translate to windows-style path
std::wstring name(logsPath.replace('/', '\\').toStdWString());
nr.dwType = RESOURCETYPE_ANY;
nr.lpRemoteName = name.data();
// login with username and password
// CAUTION: password is first in this function
int ret = WNetAddConnection2(&nr, L"1234", L"admin", CONNECT_TEMPORARY); // trivial user and password
if (ret == NO_ERROR)
{
return true;
}
else
{
return false;
}
It works well most of the time. However, there are cases where this still fails with 'ret = 5' ("Access Denied"). Retrying infinitely does not help. I have no idea why it's unreliable, but I have the feeling that Windows Explorer is trying itself to log in concurrently, using a wrong username/password (as it cannot know it) and that Windows somehow blocks the access to other processes? Can that be?
It seems that starting our C++ software long after connecting the device increases the chance of failure, and starting it directly works better.
But this makes the solution of using Windows + SMB share only ~80% reliable, which is far below what we need for our commercial product (99.9%+) that needs to be plug&play.
Is there anything we can do to improve this reliability? Are there any Windows Update foreseen that would improve the general situation with Samba and fix these issues?
The same device works 99.999% of the time from Ubuntu, with < 1 sec to connect, faster transfer speed, etc. so the issue does not seem to be on the server side.
If there is no way to improve, I guess we'll have to move to an FTP client to avoid these bugs, but the transparent integration through the file system is really nice and we would loose that.
Thank you for your help!
Alexandre H.