Originally Posted by
ianmanning
$50k to restore a feature which was lost simply by doing a routine O/S upgrade? Rolling back the upgrade would make more sense, but I thought that this was a forum where more experienced people than me could offer simple advice to resolve the problem. I guess that doesn't apply to everyone.
When that's possible, it is the goal. Sounds like you mistook my little pedantic joke. Of course, no home user would pay $50K to get something like this working. OTOH, I've known businesses where their process was so integrated with a specific feature that they spent $100K to resolve the problem ASAP.
If Morbius doesn't have a quick answer, I doubt anyone else here does. Have you tried to get MSFT to help? After all, they are 50% of this issue.
I'm not a samba expert and don't use Lubuntu or Windows10/11, but have been setting up samba since the mid-1990s both at home and at a few jobs when necessary. https://www.linuxbabe.com/ubuntu/ins...ver-file-share seems to have the most complete installation instructions that address most of the common issues along the way. I've not needed anything so complex for my smb 2.1 clients.
Code:
sudo nmap --script smb-protocols 172.22.22.6
...
Host script results:
| smb-protocols:
| dialects:
| 2.10
| 3.00
| 3.02
|_ 3.11
shows that my samba server on 172.22.22.6 supports those specific smb versions. Win10 supports smb version 3.00, BTW.
A similar question was asked and answered here: https://askubuntu.com/questions/1236...u-server-20-04 Seems using NT1 as the protocol was the highest voted answer, but a few others posted other things to try. Hard to know if those other proposed answers actually matter or not. Can't hurt to try, assuming to keep careful backups of all attempts. Seems something around samba requires a full reboot between some changes, so restarting the smbd and nmbd dæmons isn't always sufficient. Hard to known when it is and isn't required.
Complaint rant:
Routine upgrades aren't always routine. Things change which are outside our control. For example, MS-Win10 changed many things about the CIFS protocol used over the last few years. That's outside our control. They didn't ask you or me for our approval. The entire CIFS protocol implementation on all Unix-like OSes is reverse engineered. To be clear, the recent CIFS changes for better security and improved performance are generally an overall "good" thing, but the migration could have been more clearly planned with teams outside MSFT.
For a few decades, MSFT provided ZERO help to make CIFS/Samba work. I vaguely recall they helped the Samba project about a decade ago with some things.
https://www.zdnet.com/article/micros...es-5000122696/ from 2002.
https://www.computerworld.com/articl...overture-.html
For about the last 5 yrs, MSFT hasn't been nearly as nasty, but they still are a little secretive on many topics which make integrations harder than necessary. Maybe they will be more team players in the future? Hard to say. Most users are stuck dealing with the fallout.
BTW, nobody here works for Canonical and Canonical isn't the team running or coding the Apache Samba project. Perhaps the installed defaults could have been better, IDK. Whenever I've had CIFS connectivity issues, the fix was always on the MSFT platforms, not Linux.
Just Give Me the Beans!
Adv Reply
Bookmarks