First post, by neonblurb
I recently went on a mission to try to get my PC running MS-DOS 6.22 to connect to my modern LAN. I specifically wanted to be able to mount a network share on my modern Synology NAS as a local drive rather than using FTP to copy files back and forth, as my idea was to be able to store a few CD images and larger files on the network and just mount them over the network with SHSUCD as needed, freeing up a bit of space on my local FAT16 drive.
I got there in the end, but it took quite a bit of trial and error. The main issue I ran into was that however low I set the SMB compatibility on my Synology NAS (which supports dialling the compatibility right back to SMB1 with NTLMv1 authentication even in the latest DSM version), I could not get any DOS networking software to connect. I tried LAN Manager 2.2c, MS Network Client 3.0 and Windows 3.11 for Workgroups with the TCP/IP driver, all to no avail (I believe all three support NTLMv1, on paper at least). I suspected a protocol compatibility issue as the most likely thing and I didn't want to go messing about with the Samba smb.conf file on the NAS itself as that might break things in the Synology GUI, so I decided to try setting up a VM server to bridge the protocols and give me some more control for debugging/testing.
I first thought was to try setting up a Windows 2000 VM in the middle - the thinking here was that I'd create a directory as a local share, then try using junction points to link to a mapped network drive - I didn't realise that this junction points don't work on network drives, and symlinks in NT were not available until Vista. Oops. Rather than install a Vista or later VM, I decided to try using a Linux VM running Samba as a bridge, as I thought it might be easier to configure, inspect logs, tweak config files, etc. under Linux.
First to figure out if modern versions of Samba support LM authentication - it turns out in Samba 4.17 they started dropping certain LM-related features like using LM auth under AD DC configurations, so even though I wasn't using that specific I thought it would be safest to use the latest version before that, 4.16.11.
Here's how I (eventually) got this working:
- Installed Debian 11 Bullseye (the last version for which Samba 4.16.11 comes with a bootstrap script) and compiled/installed Samba from source
- Installed cifs-utils and mounted the share on my Synology NAS to to my Debian VM (persisted this via /etc/fstab)
- Set up smb.conf to use lanman auth and a minimum protocol version of CORE
- On the DOS machine, set up the network stack with TCP/IP protocol and used 'net use' command to connect to the server and mount the share
This was after quite a bit of testing and watching the Samba log files as my DOS client connected. My initial smb.conf had the minimum protocol version set to NT1, but I found after looking at log files in my Samba server that the client was failing to connect because of mismatched protocols, and then I set the min protocol version down to CORE to be safe - this was the final clincher.
A couple of observations:
- Long file names get butchered with a ~1 name replacing the long filename, although they are even less recognisable than usual (they seemed to be random characters rather than the first few letters followed by a ~1)
- If you want to test that you can connect to the bridged server using a modern Windows machine (e.g. 10/11), by default SMB1 compatibility is not installed - type Run > optionalfeatures and install "SMB 1.0/CIFS File Sharing Support" (requires a reboot).
- Modern Macs on my network would see but not connect to the bridged server's SMB share. Apparently it's possible to switch on SMB1 client support in Apple's in-house SMB implementation, but that's an adventure for another day.
- I did try getting Samba 4.16.11 to compile under Debian 12 (current at time of writing), but the Debian 11 bootstrap script didn't work and I didn't fancy playing bingo with the dependencies, so I just got a netboot image for Debian 11.
- Incidentally, using the older Samba version might not have been necessary at all. The latest Samba docs still refer to support for LANMAN protocol versions under client max protocol/client min protocol - so maybe this would have just worked with the latest Linux/Samba which would have avoided having to bootstrap/compile from source.
I took detailed notes as I went through the above setup, so let me know and I can share any details if you want to replicate my setup, but if you want to go the fun route maybe fire up your search engine/LLM of choice and work through the above for maximum fun.
Final test: copied over the my Duke3D Atomic CD's support folder onto the network share and fired up Duke3D. Duked it out with no issues 😀
