• Please review our updated Terms and Rules here

Fix for issue with DOS NFS client (XFS 1.x) on PC-DOS 7. Also, DR-DOS 6.0 issue

Eudimorphodon

Veteran Member
Joined
May 9, 2011
Messages
6,866
Location
Upper Triassic
This started as a request for help, but halfway through typing it I had an idea, tried it, and it worked. Maybe it'll be of some use to someone.

So, I started test driving alternatives to EtherDFS as a network file system for my DOS PCs. Saw a quick howto for doing NFS over a standard packet driver using XFS, tracked down a source of several versions here:

ftp://ftp.cc.umanitoba.ca/software/pc_network/

Spent some time hitting the linux server with a shoe to get it to serve a sufficiently old and insecure version of NFS, but I think I have that sorted out. Here's the problem I hit: I was able to load the XFSKRNL.EXE pointing at my packet driver at 0x60. Also had no problems running "XFSTOOL init" (after setting up an apropos HOSTS file) and I could run the SHOWMNT command against the server to see what mounts it's exporting. However, after running a "mount" command I'd get an "invalid drive specification" attempting to actually use the mount XFS saw as present.

Because I have it set up for a dual boot I went into DR-DOS 6.0 and tried the same spiel, and under that it worked. (Mostly, I'll get to that.) The fix I tried, and seems to work, for PC-DOS was to use setver to set:

XFSKRNL.EXE 5.00
XFSTOOL.EXE 5.00

I doubt both are strictly necessary, I'd hazard a guess just setting it for the XFSKRNL.EXE binary would be enough since I think that's where the actual redirector lives.

Running a full-disk XCOPY to the network now to see how it holds up. Trying to do this test under DR-DOS revealed what seems to be a bug in either XFS or the DR-DOS xcopy command: doing an "xcopy /s /e source:*.*" will only copy the files in the starting directory, when it has to create a directory it fails with a "path not found" message. (Which of course seems like a non sequitur given it should be the one creating the directory. If you create the directory for it and run it again it descends into it and copies the files... and then fails on the next "missing" target directory.)

Now that I have PC-DOS working its XCOPY doesn't seem to have that problem. Maybe it has others, that's a real possibility.
 
I do know that the FCB and file system handling of DR-DOS 5+ and Novell DOS (its successor) is very different from the "standard" MS/PC-DOS versions, so that may be the root cause.

It does, however, have some nice extensions to the built-in commands (like XDEL), picked up by changes to the MS/PC-DOS (e.g. DEL) in later versions.
 
I would be very interested in a quick cookbook of a successful NFS setup, as I've been unsuccessful trying to do this several times in the past. MSLANMAN is simply too heavy for a 640k system, and doesn't support all cards, so an NFS solution that uses standard packet drivers would be great. The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.

For example, you listed a URL but not the specific package you tested.
 
I do know that the FCB and file system handling of DR-DOS 5+ and Novell DOS (its successor) is very different from the "standard" MS/PC-DOS versions, so that may be the root cause.

Last night I upgraded my DR-DOS 6 installation to Caldara DOS 7, and, knock-on-wood, it looks like it's fixed the xcopy not making a directory issue. I discovered after my initial post that EtherDFS didn't work on DR-DOS 6 at all but it also works on 7 so apparently they fixed "something" to make it at least better to emulate the MS-DOS flavor.

Just kicked off a full xcopy of my boot drive to NFS, I'll see what happens.
 
I would be very interested in a quick cookbook of a successful NFS setup, as I've been unsuccessful trying to do this several times in the past. MSLANMAN is simply too heavy for a 640k system, and doesn't support all cards, so an NFS solution that uses standard packet drivers would be great. The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.

I'm currently using the xfs-191.zip; according to the *very* sketchy documentation I started with this version might need a "286 or higher", but it runs on my V-20 equipped HX. According to a (German language) thread I found there was a claim that the 1.8x versions will work on an 8088, but I'll admit my German is pretty rusty. I will probably try 1.8x again to see if there's any difference, I switched to the newer version in response to the problem I solved with SETVER and haven't gotten around to going back since 1.91 runs.

Unfortunately "weight" still might be an issue with this solution. The xfskrnl that needs to be loaded takes almost 64k, which is *just* too big for what's left over on my 1000 HX with its UMB RAM board after loading DOS; I might barely make it fit on the 1000 EX. (Difference is 112k vs. 128k of upper memory.) If you can't get that kernel into upper memory and you need to have DOS low you're probably looking at a 500k-ish TPA. :( EtherDFS is thus far the reigning king of low memory usage I've found for Ethernet mountable filesharing, I'd love to know if there are other solutions in its ball park.

The quick recipe for getting it going:

1: I'm pretty sure you need NFS v2 support on the server side, which most distributions don't do by default anymore. I achieved this by modifying "/etc/defaults/nfs-kernel-server" (Ubuntu) to enable said support per this support thread; If you're running 18.04 or later look for "I had to hijack RPCNFSDCOUNT to get it to use NFS v2":

RPCNFSDCOUNT="--nfs-version 2 8"

2: The xfs documentation is kind of a... thing. The quick and dirty way to get it going is to modify the HOSTS file in the distribution to look like this:

Code:
10.1.1.1	gateway
10.1.1.255	broadcast
255.255.255.0	netmask
	
10.1.1.10     server		nfs-server
10.1.1.20     myhost

"myhost" is the name of the DOS box you're running it on. Assuming you don't care about trying to authenticate or print share with pcnfsd (a can of worms I have not opened yet) don't bother with the INIT script; A batch file that loads your packet driver and xfskrnl and runs the TCP/IP init should be fine:

Code:
@echo off
rem XFS Version 1.71
rem good luck loading xfskrnl high, is big

loadhigh pnppd 0x60
loadhigh xfskrnl 0x60

rem xfstool will look in the HOSTS file for the gateway/broadcast/netmask entries
rem and apply them to the host name you specify

xfstool init myhost

rem done

Then you can try checking mounts with "showmnt server(name)", and then try mounting something:

xfstool mount e: server:/path/on/server

As noted in the docs, the tool will want to own your packet driver, but it provides a passthrough two ports higher than what it latches onto, IE, if you run the packetdriver at 0x60 you *should* be able to use the mTCP tools or whatever by pointing them at 0x62. I have not tried this yet.
 
I've used XFS 1.91 on my Deskpro 8086 with V-30 upgrade and Compaq MS-DOS 5.0 for a little while. I never was able to figure out the whole authentication thing, so it basically mounts the NFS drive read-only (the login part of the init script fails). But the thing that is kind of a deal breaker is the upper-case filename mangling. If a filename fits in the 8.3 format and is lower case on the server, it shows up as an unmangled filename under DOS. Anything else gets mapped to essentially random characters. But all my DOS files are upper case on my server so I found a script to rename all the files in a directory to lower case. Quite the hassle.

There are also some incompatibilities with certain programs. I use PFM.COM, Paul's File Manager (if you worked at Compaq you used it and your fingers are still programmed to its keystrokes), but it crashes out any time it touches the mounted drive. PFM.COM works fine with MSNET. Other file operations will crash out on occasion, XCOPY and such.

If I could figure out the authentication so I could write to the NFS server, at least it would make for another option to copy files back and forth. As it is, mTCP is the solution of choice.
 
For whatever it's worth, booted under Caldara DOS 7 an XCOPY of about 120MB of files just completed with zero errors or premature pooping out. It's probably worth noting, though, that this doesn't seem to be a particularly *fast* solution. That copy took something around 4 hours, so that's around half a meg a minute, or only 8-9k or so a second? So...

The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.

Unless your XT is a lot faster than mine you'll probably grow pretty old and gray copying more than 8GB. ;)

(For comparison, I ran mtcp's spdtest after doing the copy and my connection to the server benched at about 64k/sec upload, 56k/sec download. So wire speed it sure isn't. It has an option to turn off checksumming, maybe that makes it faster. And, for the record, running through the XFSKRNL's packet proxy didn't work for mtcp programs, I had to use xfstool to disarm the NFS share for speedtest to work.)

But, again, it does seem to "work". The mounted filesystem had about 77gigs free on it, I have no idea how much you could *actually* manipulate from the attached DOS box.
 
Last edited:
If I could figure out the authentication so I could write to the NFS server, at least it would make for another option to copy files back and forth. As it is, mTCP is the solution of choice.

Writing works fine for me with no authentication by just exporting it with the right options on the server. I did note the file name limitations, so it's definitely not ideal if other OSes touch the same share.

Calling the authentication stage is an entirely optional layer; any security you're going to get out of it is practically speaking kind of a joke. I'm mildly skeptical about my chances of even getting pcnfsd to work on a modern Linux machine, nobody packages it anymore. Maybe it works?
 
Other file operations will crash out on occasion, XCOPY and such.

So, this is a thing that actually got me looking at alternatives to EtherDFS, because I've discovered that if I try doing a *BIG* XCOPY to a mounted EtherDFS share it usually fails. There's no error message, just at some random point during the copy XCOPY just poops out and tells me it's copied x-many files which is some random-sized subset of the full copy. I assumed it might be some limitation with XCOPY until I swapped my SD card hard drive for a bigger one with multiple partitions and did an XCOPY of all of C:\ to a directory on D: and it completed 100%

I've tried the same XCOPY test with XFS and the same thing happened, XCOPY just bailed at a random spot, so it seems to be a general problem with network drives or... something? This is under PC-DOS 7/2000; I've been meaning to but haven't prepped a boot disk to try this with other Microsoft-based DOS-es like 6.22 or 5 to see if this is a PC-DOS specific thing. It happens on two different machines with the same OS build on them.

Since XCOPY doesn't return an error message I have *no idea* what the failure is, so far as it looks it's like it's just decided it's copied enough files today and it's done.
 
So you've inspired me to return to XFS. I just made a new share and gave the directory full permission to everyone. Not something I was willing to do to my home directory. Lo and behold, XFS can read and write to it. I see the user/group of nobody/nogroup writing to it. So that will be a workable solution for the times I need it.

Thanks for the inspiration to continue fighting it.

One of the things with XCOPY that I believe causes pain is the filename remapping somehow comes into play and the same mangled name is re-used causing infinite recursion. Just a thought. PFM.COM crashes out with: "runtime error 200 at 0102:145C." (just typing "DIR" on the drive will show that at the end of the listing) whenever touching the mounted drive. Whatever that means. On further review, it appears to get that error when displaying the free bytes on the volume. Hmmm.
 
Last edited:
So you've inspired me to return to XFS. I just made a new share and gave the directory full permission to everyone. Not something I was willing to do to my home directory.

Heh. You could tell the server to lock down the allowed clients to a specific IP, but, yeah, generally speaking I'd say any network service you run for such ancient and fundamentally insecure purposes you should either consider a confidentiality-free zone or needs to be strictly air-gapped.
 
I don't want to copy that much -- I want that much (and more) accessible on-demand. For reasons.

If it's mostly going to be reading then I'd definitely look into seeing if some of the no-checksum and other options speed it up. I was also running over a combination of wifi and a known-cruddy ethernet bridge, which may have made it *particularly* troublesome.

(To a wired-on-the-same-segment host Speedtest manages about 50% better results, which gives you an idea of how awful that ethernet bridge is. Was too lazy to move a server to the other side for initial smoke tests.)
 
I have using XFS v1.91 for years and it's an awesome piece of software. Here is a howto to setup it:

http://wiki.freedos.org/wiki/index.php/NFS

The howto mentions a specific 8086 version which I was never able to find ...

This is my configuration:
* Client side
I use this to start/stop the client
Code:
@ECHO OFF
:: XFS start/stop script
IF .%1 == . GOTO start
IF .%1 == .STOP GOTO stop
IF .%1 == .stop GOTO stop

:start
:: use your own packet driver
loadhigh d:\drivers\pcipkt 0x60
::loadhigh d:\xfs\winpkt 0x60
loadhigh d:\xfs\xfskrnl 0x60
d:\xfs\xfstool @init
GOTO end

:stop
d:\xfs\xfstool @fin
::d:\xfs\winpkt -u
:: use your own packet driver
d:\drivers\pcipkt -u

:end
Run startnet STOP to unload the hole thing and free the memory.

This is the "init" file
Code:
#
# XFS Start Command Script

init i486 sm=255.255.255.0 gw=192.168.2.1 csum=off

# authentication
# You need the pcnfsd daemon for this to work
#pcnfsd debian
#login

mount z: debian:/srv/nfs
mount lpt1: debian:canon timeo=30

show
rdate debian

and this is the "unload" script
Code:
#
# XFS Stop Command Script
#

show
umount all
#logout
unload

You also have to configure a hosts file on the client to resolve host names (i.e. my nfs server "debian" is 191.168.2.6)

* Server side:
You need to configure an /etc/exports file:

Code:
# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
/srv/nfs       192.168.2.0/24(rw,sync,no_subtree_check,all_squash,anongid=999)
192.168.2.0 is my home network. I map all NFS users to group "share" because I have the group suid bit enabled in directory /srv/nfs to preserve the group ownership on newly created files.

Code:
$ ls -l /srv/
total 24
drwxrwsr-T 6 nobody share 4096 may 30 08:13 nfs

You only need the pcnfsd daemon to authenticate users and print. I have a debian (and RPM) script to build such packages.
 
Last edited:
I forgot to upload the debian package sources. Here it is:

View attachment pcnfsd.zip

to build it:

1) Extract the contents of the zip file
2) Go to pcnfsd/pcnfsd-2.0.build
3) Run dpkg-buildpackage in that directory

it will create a pcnfsd_2.0-4_amd64.deb package in pcnfsd with these contents:

Code:
$ dpkg -L pcnfsd
/.
/etc
/etc/init.d
/etc/init.d/pcnfsd
/etc/pcnfsd.conf
/usr
/usr/man
/usr/man/man8
/usr/man/man8/rpc.pcnfsd.8.gz
/usr/sbin
/usr/sbin/rpc.pcnfsd
/usr/share
/usr/share/doc
/usr/share/doc/pcnfsd
/usr/share/doc/pcnfsd/changelog.Debian.gz
/usr/share/doc/pcnfsd/copyright
/var
/var/spool
/var/spool/pcnfs

This works with debian 7 I haven't tested it with more current versions.

I have also a RPM source package to build pcnfsd under RedHat/CentOS but I wasn't able to find it.
 
I have using XFS v1.91 for years and it's an awesome piece of software...

I will definitely see if I can get pcnfsd working. I don't really care about authentication (because, really), but the printer redirection could be interesting.

Have you had any luck getting mtcp tools to use the redirected packet driver socket? It's not really that big of a deal, considering it's DOS we're talking about it's not the end of the world to not have shared filesystems and "internet" at the same time, but it'd be nice if it worked.

On a kind-of-related subject just for laughs today I tried to get the Personal Netware that got installed with Caldara DOS 7 to work. That was a total bust. I don't think a Tandy 1000 was exactly the target platform; if I have my EMS driver loaded it hangs on startup trying to load some of its massive suite of modules with EMS support (I wonder if it's because it's not a "real" EMS 4.0 card), and without EMS it leaves about 400k of DOS memory, and didn't seem to see the mars_nwe server I set up at all, although since I basically know squat about Netware that could certainly be my fault.

Oh, I also tried xfs with "csum=off", and it does seem to make it *much* faster. Maybe on a "real" computer it wouldn't make much difference, but at 7 mhz, yeah, it's significant.
 
Have you had any luck getting mtcp tools to use the redirected packet driver socket? It's not really that big of a deal, considering it's DOS we're talking about it's not the end of the world to not have shared filesystems and "internet" at the same time, but it'd be nice if it worked.

No, but if it doesn't work you can try PKTMUX:

ftp://ftp.cc.umanitoba.ca/software/pc_network/pktmux12.exe

there is a sample setup in the XFS User's Manual
 
PKTMUX does indeed work. It adds another 19k or so of resident software, but since XFSKRL doesn't fit in upper memory on my machine anyway there's no net damage, I guess.

Under PC-DOS 7 on a machine with 624k base memory (yay Tandy) and 112k upper memory the total damage with an NFS share mounted and the packet redirector set up for MTCP is 564,864 bytes conventional free sitting at the DOS prompt. (552k) Could be better, but I've seen much worse.

You do have to be very cautious about filenames on the NFS side, that is most definitely a thing.
 
You can use XFSKRNLM instead give up printing and recover 9KB. There are several name mangling options for the client but, IMHO, the best one is use defaults and make sure all your files are in lower case letters and 8+3.
On another matter, I tested all 1.8x versions I could find and definitevely they don't work with 8086/8088 processors.
 
Back
Top