I had some annoyance while switching from samba 4.12.15 to 4.13 (and any newer versions): The volume IDs/serial numbers shown by the Windows command "vol.exe" changed in the newer version. We're using a third-party software that relies on serial numbers to check whether its license is valid, so a change in the serial numbers made our third-party software unusable. I did a bisect on the codebase and discovered that commit 7a7b597b3dfcbabf5de92222aef207421cd6b4ea was responsible for changing the volume serial numbers. Right now we'll use a custom version of samba with this commit reverted, but I'd like to report this so it can be fixed in the upstream. In case there's other ways to tell samba to use a fixed serial number, such as a configuration option, help will be welcome. Unfortunately, I only saw really old, unanswered mailing list emails related to this subject. So I'm unaware if there exists a method to do this.
Well that is a strange an unexpected side-effect. Sorry.
OK, the relevent code is: /* Return volume name */ /* * Add volume serial number - hash of a combination of * the called hostname and the service name. */ SIVAL(pdata,0,str_checksum(lp_servicename(talloc_tos(), lp_sub, snum)) ^ (str_checksum(get_local_machine_name())<<16) ); How about just adding a new share-level parameter, lp_volumeid() that allows a user to explicitly set a value that will never change for a share ?
Would this setting be in the /etc/samba/smb.conf file? If that's the case, it sounds like a great idea!
Yes, it would be something like "volume id = 0xFOOBAR" in the [share] section of the smb.conf.
Which software is it that does such a weird check? It will also stop working if you have to restore data from a backup to a new disk then? That sounds quite broken.
It's a very crappy accounting software written in FoxPro. It has been quite unreliable besides of this bug, but sadly we inherited it and it would be hard for us to switch it for a more decent solution :( When volume's serial changes, the program fails to run and requires a support team to manually connect to your machine via TeamViewer and re-activate the software. That's how bad it is. I understand this software relies on undefined behavior to perform its license check, and that what I reported might not be an actual bug. But I think there might be more software like this that relies on volume serial numbers.
(In reply to cript0nauta from comment #6) Ouch! My condolences on needing such strangely written software! As some patches are being written for this I've linked the MR.
This bug was referenced in samba master: 470d4a3b61bc6924edcfc1453b01d7d6a8a6abdb 5f1f3b0f06327753ee939158c5ef826cc9514249 7ba732bac12319492da7cf8bafc268014a80360d
Will be fixed in 4.17