Arf, arf, arf!
Must be some real BOFH bellends about if business system are still on SMB1
The Windows 10 April 2018 Update has been out for over a month now, and the rumbling of user dissatisfaction continues. This time it's networking problems for users still clinging to the venerable SMB1 protocol. Users have taken to support forums, including Microsoft's own, complaining that the latest version of Windows 10 is …
May I point you to medical hardware?
As a rule-of-thumb, any medical hardware that needs a dedicated control computer with a specific OS version (e.g. WinXP) should not be networked (or on an isolated network with its own e.g. file server). It's not going to have a problem with SMB1, as it won't be using SMB, unless its partner hardware requires it - which will also be kept off any general network, and certainly never let near t'interwebz.
SMB is a bit naff (and its actually well over 30 years old) but -- and this is a big BUT -- being an 'old' protocol doesn't necessarily make it a bad protocol.any more than being a 'modern' protocol makes something good. I've noticed a tendency for modern code and protocols to be both bulky and bandwidth hogs, attributes that open up all sorts of failure modes but in the general haze of inefficiency its just easy to point the finger at something else and claim that one's own work is perfect. Not true.
(Incidentally, 'pure' SMB is so old that it can't run on a routed network so its pretty difficult to abuse or hack. What most people see as SMB is a protocol running on UDP.)
Most stuff is OK to transmit in the clear. For the really sensitive stuff, like backups, it should probably be stored in encrypted form and so transmitting in the clear is fine. For other stuff, if you are still bothered, a better option is probably to use IPsec and then stop worrying about whether your various higher level protocols have encryption built-in. Sadly, IPsec appears to be stuck in the same tar-pit as IPv6.
I haven't heard of this so assume it hasn't happened. But if not it would of been nice for MS to pop up a warning message when connecting to SMB1 shares to alert the user. More props if they pop up a warning for SMB1 capable servers even if the clients are able to connect via a newer version of the protocol.
I'd wager ~98% of the users out there have no idea what SMB version they might be using(or even how to tell). I count myself among those. My usage of SMB is quite small though I do have a samba system at home, just doing a quick check on Samba and SMB v1 I came across this article for how to turn SMB v1 off:
https://www.cyberciti.biz/faq/how-to-configure-samba-to-use-smbv2-and-disable-smbv1-on-linux-or-unix/
I checked the config (fairly default config) on my system and there is no mention of the "min protocol" setting(don't know what the default is for Samba 4.2), so maybe SMB v1 is enabled, or maybe not. The only clients that access it are windows 7, and there too I really have no idea what protocol version they use to connect.
(small disclaimer linux has been my main OS of choice desktop/server for 20 years now, though I have used windows from 3.0 -> 7(client) windows, and I do manage a dozen or so windows server VMs(win2k8 and 2k12) as well, so not totally green)
Same goes for enterprise stuff, I have SMB on an EMC Isilon cluster(code is fairly current) but no idea what version of SMB it runs(a quick search shows one person wanting to disable SMB v1 on Isilon 2 years ago, and another person suggesting a specific code version that introduced the option to disable SMBv1)
"I'd wager ~98% of the users out there have no idea what SMB version they might be using"
98%+ of the users out there probably have no idea what SMB is so a pop up warning will just result in another call to IT support and a response that will probably just reinforce the "dont worry just click ok" mindset that these warnings can engender
It's could be a bind if you run say RHEL/CentOS 6 which is still supported by RHEL to which you may be locked for support contracts etc.
Until quite recently there were no Samba 4 packages available for it, apart from Sernet who then pulled their open source packages behind a paywall some time ago.
RHEL slipped out some S4 packages a while back but they are only at 4.2.x and W10 I believe really wants 4.3.x + for SMB 3.1+
Messy. Probably even worse if you run a NAS and rely on upstream firmware.
If I had my cynics hat on I'd almost say 'contrived'
But that would be too cynical, wouldn't it?
...Win10 Pro and above have natively supported being an NFS4 client. It just works, once you enable it. In fact, if your NFS server is exporting a volume formatted with ntfs-3g it works for storing backups. With the right export options you can even store a Win10 system image. Imagine it: Win10 accessing a mapped network drive like a *nix client and treating it like a native MS server share.
Now, I know there has to be a down side to it. I just don't know what it is yet. What I do know is that I don't need SMB on my network anymore. Thank RNGesus for that!
Ditto, as someone who rarely uses windows but has been using linux and unix for years i've rarely seen kernel panics, and those i have seen were usually down to either hardware faults or me testing/writing experimental kernel patches.
The few times i've used windows, or seen someone else using it, i always wonder how they put up with it. Just last week a friend of mine was unable to connect to wifi and had to reboot before it would work, and after rebooting the system was sluggish for several minutes and inundated with focus-stealing popups.
To be fair, since Vista (when Microsoft changed the way drivers were allowed to interact with the kernel), the only BSoD's I've seen have been either bad hardware, or bad drivers/software.
I've still probably seen more BSoDs than kernel panics, but that's partly because most of the linux machines I interact with are servers, with the higher grade of hardware that implies.
BSOD's on the other hand, are a frequent occurence
I don't think I've only ever seen a BSOD when there's not a hardware fault. The last time it was a faulty RAM module, and the BSOD message was diagnostic enough to be able to google it and then pop in a memtest86 boot CD to diagnose it properly.
Maybe back in the mists of pre-history I might have seen one or two on a 386 running Win3.1, due to dodgy drivers or IRQ conflicts.
The BSOD has been available for Linux since 1998:
This post has been deleted by its author
@soulrideruk
Please forgive my extreme amplification of Bob's posting style. I was just trying to make a point, perhaps it didn't work.
As far as my views on windows go: I hate it with a passion. For over 25 years I have been a passionate user and supporter of FLOSS. However I try not to let my idealism get in the way of actually being able to do things and using the best tools for the job.
Sadly, sometimes that means I have to use things like Windows, Java, systemd based distros, gasoline engines, dish-washing detergent, and a whole legion of other first world problems. Happily, I get things done every now and then.
Anyway I gave you an up vote because I didn't think your comment was bad enough to deserve the down votes.
Linux is not without it's faults.
Seems like even "secure" distros (no GUI) are now experiencing memory leaks due to questionable scripts being enabled by default.
These bugs are being called "mostly cosmetic" by their authors even though they are listed as known exploits.
Things went downhill rapidlyafter systemd was introduced.
"Now, I know there has to be a down side to it. I just don't know what it is yet."
I don't know either, but I do know that the Samba people have put in a lot of work over the years trying to find interoperability compromises between the Windows and UNIX rules for filenames, user identities, security descriptors and locking semantics. It more or less works, so if Microsoft have studied Samba's efforts in detail and put in a similar amount of effort in their NFS client then you'll be fine. (That's not impossible, People like Ned Pyle do appear to be very familiar with Samba.)
Imagine it: Win10 accessing a mapped network drive like a *nix client and treating it like a native MS server share.
So exactly like Win 7 then, although hopefully with a few fewer bugs.
I was rather hoping they'd have managed to do the same with sftp by now in Win 10.
But on my way whom a colleague contacted me to say they couldn't reach a fileserver which happens to be W2003.
Now colleague is on Win7Pro and they haven't installed any updates (because in a hunt for free space on another server, a third party IT provider deleted the WSUS db thereby knocking out any new updates)
But this is a good spur to replace the 2003 server.
Why do I have to be constantly reminded that the aging AS400 we have at work is running an out of date version of the OS and only supports SMB1 without which we can not send direct debits.
Sigh. Its not fun when you give the financial users a brand new dell laptop with which they process the direct debits via the ERP on the AS400 to then have them phone up when the client software on their laptops no longer sends the direct debits because a windows update was installed that turned off smb1 so the client software can't write to the ifs on the AS400. They then call you expecting a fix in the last few mins of the day OR NOBODY GETS PAID their monthly salary, including you!
Talk about pressure followed by flood of relief as you manage to turn it back on.
Then you sit back wiping the sweat from your forehead and wonder why MS can't let you override it by group policy that you can apply to only certain laptops as needed while you wait for the big wigs to finish approving the migration to the new cloud based ERP which keeps getting pushed back month by month no matter how often you tell them what smb1 is and why MS keep trying to kill it and how that should fast track the new ERP approval.
So you are angry with MS wondering why you are not in full control of your computer thus realizing Richard Stallman was right after all and angry at the big wigs for wasting time stuffing their faces at as many meetings they can find an excuse for, while waiting till pay day knowing that you will go through it all again.
No wonder I love reading Dilbert.
So your organisation depends on a propietary 3rd party protocol for a mission critical service. Do all of your vendors support indefinite end of life?
Probably not. Boo hoo.
The important thing is to strictly control the reach of any protocol and manage interfaces appropriately. Not rocket science, and never has been.
"wonder why MS can't let you override it by group policy that you can apply to only certain laptops as needed while you wait for the big wigs to finish approving the migration to the new cloud based ERP"
Perhaps you could arrange it so it's just their salaries that don't get paid one month...
Well perhaps someone should have thought about that before implementing a critical system using such a poorly designed protocol...
Really the problem is that SMBv1 was so badly designed in the first place that it needs to be turned off for security reasons. There are plenty of other protocols that are old and still in use and also still widely supported by backwards compatibility even when newer versions also exist.. SMTP/ESMTP, HTTP 1.0, DNS etc.
I think microsoft has a point here. Never mind that the protocol was made insecurely; that was a problem before but it's just reality now and it has to be dealt with. Microsoft can't seem to get people to change from one protocol to the next version that is more secure just by making it available. SMB2 is twelve years old, after all. In that case, it may be needed to add an incentive for that to happen. Sure, it'd be nice if nothing ever broke and people only had to upgrade when they wanted new features, but that's not how software works.
A month ago, I found this old device with an ancient linux kernel on it (version 2.6, proprietary interface on it) in my closet. I played around with it, trying to see if you could run modern stuff on it. The device had no package manager and no C compiler, but it did have various other packages and python. So I tried to download some code from github, and what happened? It wouldn't download because github had instituted a security policy the browser didn't support. I'm not quite sure what it was. I think this is new enough to support https in general, so I assume it was a new version of SSL. So, technically, SSL changed its security policy in such a way that my device couldn't even browse the internet. Still, we want that kind of thing to happen because if we just left it out, we wouldn't have security. We'd have plain HTTP, and whatever version of SSL we started with. That version has become insecure, so we've canceled it. Security requires protocols to change. Sometimes, that means we can't use our windows 2003 servers anymore because it's now 2018. In my case, it means my powerhouse of a 520mhz ARM processor from I don't know how old with its 64mb of ram can't be expected to go online anymore. Of course, if the hardware on which it was running was that important, we could always reinstall it with something modern. Sometimes, that's just how things should be.
"They then call you expecting a fix in the last few mins of the day OR NOBODY GETS PAID their monthly salary, including you!"
Or the people who would have signed off the updates on the AS400. You had a useful tool there.
But you probably still do, as SMB1 will be forcibly disabled sooner or later, probably sooner.
you wait for the big wigs to finish approving the migration to the new cloud based ERP which keeps getting pushed back month by month no matter how often you tell them what smb1 is and why MS keep trying to kill it and how that should fast track the new ERP approval
I don't see any mention in there of the thing you should be telling them.
>>>> NOT doing the migration costs X amount of money in lost productivity etc. every single month.
Speak their language: Quantify the cost of not doing it.
@as400 AC (if you ever read this, it’s been 2 days since your comment): what are you running ? And are you using smb with the as400 as a host or a client ? I’ve switched over to qntc a long time ago (when we were running 5.4 or 6.1), as then the as400 acts as a client and gets its files from a windows file server. And that file server is the one where the users put their files, which might have a share that still supports smb1. Oddly enough that gave better results.
Posted as AC as well, since I want to keep that as400 my dirty little secret.