Samba 4.16 release strips away more SMB 1 The Samba project just released version 4.16, and with it parts of the veteran SMB 1 file-sharing protocol are being permanently removed. Among other changes, Samba 4.16 removes the SMB 1 commands that allow a client to request the server copy a file without sending it over the network, and server-side wildcard expansion. Both …
Sorry, I beg to differ. Those games that use palette switching 256 colors mode doesn't run on Wine. Those games won't even run on Windows 95 if your color is set to 16-bit or higher.
Source: I tried running several Broderbund Living Books titles that I never got to enjoy in my childhood.
Did Win98 not have the unix tools? ie the ability to connect via NFS? I'd assume NFS2 if so, so some work to be done to talk to an older NAS box. Failing that, there's always FTP. Not as convenient as mounting a network share, but still useful. Also some work to be done on firewall rules to make sure it's not exposed in or out! But anyone running Win98 on a network should already be paranoid :-)
I cannot remember if Cygwin supports NFS but the old Interix/SFU/SUA does. Is that even available any more? I think the last version ran on XP and maybe 2k3 but that was it.
perhaps a legacy client-only version of SMB1 could continue (so you can use smbclient to access shares on legacy versions of windows that do not have SMB2) but as far as operating as a server, I do not want it configured to use SMB1 for any of my Samba daemons...
From the article: Though SMB 1 is disabled by default in today's Samba, there's an ongoing effort to allow the project to be built without it entirely.
Yes. A configure option would be PERFECT.
(And maybe also an option to build an SMB1-friendly version of smbclient for those who might want it, maybe call it smb1client)
People are too paranoid about clear text protocols. If you're running FTP on your LAN (which is the only place something like SMB would be run can't imagine anyone using over the internet same goes for NFS), and you are worried about man in the middle you got way bigger problems than FTP if you already have an "attacker" on your inside network with the ability to intercept that traffic.
FTP is probably less vulnerable, in that there are generally far fewer "exploits" against FTP servers than SMB systems.
Argghhhh. Don't remind me. I'd successfully blocked pcNFS out of my memory :-). I used to have to support that PoS at Sun. It's existence is one of the main reasons Samba exists today (I'd left Sun, needed a cross platform network file system and someone suggested pcNFS. I restrained myself and didn't hit them. So I went looking on the (early) Internet and tridge announced the first version of smbserver. The rest is history:-).
PcNFS is the reason Linux NFS server is in kernel and doesn't play nice with anything else in userspace
It was the only way we (I was one of the people testing it on the user side) could make it work at any acceptable speed (on ancient 8 bit Ne2000 clone cards) and the idea of locking/simultaneous access from different protocols didn't even cross our minds
Ah, the days of youthful naiveity and "wanting to get it done".....
Yes, I had the MS NFS client running on Win98.
But it turned out the using NFS was actually more painful than installing and using the SMB1 client on linux (EEEBuntu) -- NFS doesn't support the record locking features provided by SMB1 -- so for us that was a dead end.
NFS is a very old protocol: there was also a NFS client for Win 3.11
What to do when we want to look at our computing history in a live fashion? We can archive all the current software and run in a (complex) future sandbox. We see this for even more ancient systems, which are emulated. We then also need ancient software to run for reasons of functionality and compatibility.
The question of archiving and preservation is whether it should be extended to all software. That means inclusion of the virus/malware/... software that will attack the archive and content while running in a sandbox. Maybe even an accidental inclusion of malware in the archive can create interesting scenarios for future archivists, historians and digital archeologists. We may dumb down if we do not preserve the entire history and the historians/archeologists get the wrong impressions of what actually happened.
One of the problems with SMB v1 was that the code was never properly documented, so when they came to fix things, nobody knew what the code was doing or why.
Given that SMB v1 has been considered a dangerous for well over half a decade, nobody should be using it on an open network or one that is connected to the Internet.
Unfortunately, there is the small problem of MFC devices with their scan to folder insisting on SMB v1 either by default or as the only option. Not to mention industrial equipment. The latter can easily be put on isolated networks for safety, but you'll pull scan to folder from clerical users' cold dead hands...
Back in 2000/2001, when out in the Bay Area, I recall being told that MS were in the habit of making small changes to SMB which clearly had no functional purpose.
The person who told me that was one Jeremy Allison. :-)
Well, it's a couple of decades ago and my memory's not perfect, but I definitely understood that while there may have been no overt MS policy to break Samba, doing so was certainly not discouraged and the most plausible explanation was that MS were probing how fast the Samba team reacted to these changes. The answer being, of course, "immediately".
I see this as a good thing however over the past couple of years on my home network I had to enable it for old devices such as security cameras and media players. Sure it's a security risk but if I'm not exposing it to the internet then what's the problem? I don't use it now but what about people that do?
well if a machine config'd to use SMB1 were compromised, it's theoretically possible to crack the rest of your network, depending.
This is why I would not allow any Samba SERVER to support SMB1, but would stlll want at least a version of smbclient to support it to access legacy windows computers that have no SMB2 support.
I'm planning a blistering broadside bludgeoning (as it's 'El Reg, gotta use alliterative headlines :-) on the concept of symlinks at this years SambaXP conference.
https://sambaxp.org/
(it's virtual, so you won't have to travel to Germany to attend). symlinks have ruined the POSIX filesystem API. I'm going to explain why, and talk about what can be done about it.
symlinks have ruined the POSIX filesystem API
I completely disagree. There is NO other way to alias a directory except with a symlink for "reasons".
/me uses symlinks a LOT and it's integral with programs like busybox (common for embedded) that have to use the program name you invoked it with in order to determine what functionality to implement.
Symlinks have been around since before UNIX anyway. Data General used them, for example.
(or did you mean something different?)
They are a mess though, with some utilities defaulting to following the link, and others working on the link itself.
e.g. stat(1) defailts to the link itself, unless you use '-L'
chmod(1) and many others follow the link, unless you use '-h'
touch(1) follows the link unless you use '-h', but the referenced file of '-r' is always followed regardless.
And of course, the classic test(1) which follows the link unless you are testing to see if it's a link,
so testing '-L' and testing '-r' on the same object will be true if you run it on a link to a regular file.
I.E. It will report the object is a regular file. It will also report it is a link.
I do note that my samba share with symlinks doesn't work correctly, but I guess that's a bug.. I use all sorts of weird and wonderful characters in filenames, and use catia mappings in smb4.conf to sanitize them for SMB clients.
Whilst the mapping are applied successfully to directories, files, and soft links, the mapping don't appear to be applied to the contents of the link, i.e. the file it points to!
>Symlinks came to UNIX from BSD. Where BSD got the idea from, I don't know.
CTSS on IBM 7090 had files linked by name in 1963.
also: "MIT Compatible Time-Sharing System c. 1963 and Incompatible Timesharing System {1967} both have linked files"
There is still a lot of old expensive industrial equipment that requires obsolete communication protocols as their control computers can not be reasonably upgraded (downtime too expensive/regulatory problems/lost source code/supplier gone bust etc). About the best that can be done for such a situation (assuming that there is the budget) is to use a small Linux box as a protocol converter (and firewall) for each such item. In the absence of such a budget then whatever connects to the old equipment has to talk the old protocols - and if this means they have to run Win98/Win2000 etc so be it.
Icon for one of the modern "agile" programmers faced with doing maintenance on a program running on Win98 in 2022 =======>
True. I also know of some major movie studios that still have FTP as part of their workflow, speaking of old skool protocols. But this isn't just about supporting some specialty PCI-x device controller card where no other driver can be found in the 32 bit world etc- this is about maintaining a network protocol with will known and severe vulnerabilities. SMB1 is a security hole that can also be used to view files.
If a device requires SMB1 it should be absolutely sandboxed from everything else, which sorta defeats the point of a NAS protocol in the first place. If you are a home user, hey, it's your lookout, but for those critical infrastructure control systems - if they are doing file based workloads and are truly critical - they are an attack surface and the threat should be mitigated before I get to read in El Reg about the latest crufty old infrastructure being brought to its knees by skript kiddies
Also - SAMBA still sucks. Now it sucks slightly less, but it still sucks.
We aren't talking about PCI-x devices and drivers, we are talking laboratory equipment that costs 5 to 6 figures and still having a useful lifespan, or production lines running well into 7 or 8 figures. Those are often expected to last a couple of decades.
Are you really going to throw away millions of dollars of kit, just because it only supports an older protocol that is no longer secure? Or are you going to isolate it onto its own network, which is air-gapped from the rest of the business and the outside world?
Well that linux protocol converter won't be running a current version of Samba.
You can understand why: SMB1 is a complex protocol, and over TCPIP the latency is bad. The only reason MS continued support was to support old unix implementations (they got a mega --- load of criticism for "breaking" open source when they defaulted to more robust authentication protocols), and Samba has reached the same point.
There are still some MFCs around that insist on SMB 1 for "scan to share" functionality. Some offer FTP as well, but not all of them and not every admin wants to put an FTP service on their file servers, just so that users can scan documents to their home folder. (That said, no admin in their right mind wants to enable SMB 1 on a file server either!
What to do when we want to look at our computing history in a live fashion? We can archive all the current software and run in a (complex) future sandbox.
it suddenly dawned on that this is probably what nature has been doing for billions of years ....
Where's my noble prize ?
I have a network scanner, Canon ScanFront, and while it's running the latest available firmware, it can only write to an SMB1 exposed fileshare.
Thank you Samba for keeping this out of landfill. It's a great device.
We scan and just pick up the scanned image off the drive.
I'd like to keep the device for as long as I can (hint).
Same here. Picked up a D-Link DNS-313 for super cheap from a bargain bin at a computer store that's going out of business about a decade ago. Device only supported SMBv1 for reasons unknown and is said to not support Windows 8 or newer. D-Link claims that the device is end-of-life and refuses to put out an updated firmware for it - storage is not an issue as the firmware lives on the disk- I triaged that greed is the real reason and they simply want me to buy a new NAS. Pfft, if the NAS doesn't cost less than US$25 (which that DNS-313 did), no.
I find it a bit odd that making some potentially incompatible changes (removing functionality, even if it's deprecated and outdated) is done in a .01 version release. You'd think it'd at least warrant a .10 version bump. That said... *shrug* if you're running XP or 98 still, you don't have any issues running old and out-of-support software so I'd just go ahead and run an older samba version with it (well, maybe it doesn't matter now but when SMB1 is totally removed.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
