It is always easy to say other peoples job is easy....
Yep. How often have any of us said "how hard can it be?" when contemplating doing something, and then we actually go try it, and find that it's
far more difficult than we originally anticipated?
I dare say that many of us have been through that.
It's something to always keep in mind when looking at something. You have to have a pretty deep understanding of how something works to be able to say with legitimate confidence that a change to it would be easy.
You'd think that the change here shouldn't be hard. And compared with some other things, it might not be. But remember that they have to do this
right.
It turns out that I have direct experience with the problem seen here, in a product I maintain at work. To do this right, you have to attempt the mount using various option combinations until you succeed or until all of them fail. Worse, mount failures can occur for all sorts of reasons, which means that unless you want to try all of the option combinations one by one (which, if the issue is that the remote server is off the air, means the total time before you accept defeat could easily be longer than the user would normally tolerate), you have to examine the actual error returned, parse it (I don't see anything in the mount.cifs manpage that describes exit codes), and figure out what it implies.
So, yes,
if all you're interested in doing is mounting a version 3.0 CIFS share, then that is straightforward. But what Siglent is really interested in doing here is mounting
any CIFS share of
any version, because they cannot know in advance what version of CIFS is in use on the target server.
Now, I don't know what version of the Linux kernel they're using here, but this is what the mount.cifs manpage says about the version argument:
The default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.
So if the kernel version in use by Siglent is 4.13.5 or higher, then the failures seen here are likely due to something other than the version itself, and Siglent would have to explicitly specify 1.0 or 2.0 to attempt mounts against those versions. Conversely, if they're using something earlier then the protocol version used by default will depend on the kernel version they're using.
And that's just the version argument. There's also the question of what password hashing mechanism the mount attempt should use, something that also differs by target server. Now the number of option combinations you need to try has increased severalfold.
There may be additional options that could make the difference between success and failure, and each of those would increase the number of option combinations to try by at least twofold.
With all that, you can see why Siglent likely chose to use the defaults when attempting the mount (without knowing the specific command line arguments they're using, I can't say anything definitive).
Mapping is NOT being done from command line. It is being done from GUI, and with code.. So that has to be changed and checked. Which is a bit more involved than what you say.
Mind you, it is not huge job, but it is a job and a test and a...
They literally have better (as in more important) things to do.
Yep, exactly. Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.
People asked Siglent for LAN mapping, and they did it... Not perfect, but hey, that can be fixed. But they listen, apparently.
Unlike others..
I wonder how long it'll be before nctnico changes his mind about Siglent ...