Find anything useful on this site? Then drop me an email and let me know.

Download by clicking here. Contribution section is here.

A completely free, working NFS V2 server. If you use this, send me a quick email!

"WHAT THE HECK IS NFS?". If this is what you're thinking, the chances are you don't actually need an nfs service, but here's a quick description anyway. If you have 2 windows "boxes" (call them 'Fred' and 'Ginger') on a network and you want to e.g. access the C drive from Fred on Ginger, you can type "net use \\Fred\C$ H:" on Ginger. Now if you click on the H drive on Ginger, you get the contents of the C drive of Fred. If you do this you're using a network file service called SMB. If you're on a unix box, and want to access a directory on another unix box you can do the same using "sharefs / share / exportfs" and "mount". This is using NFS. What if you want to share between Windows and Unix? Most people use a free package called Samba - this is SMB for unix. Suppose (for whatever reason) you didn't want your unix box to talk SMB, you want your windows box to talk NFS? Windows doesn't come with an NFS server (unless you've got NT 4 and the unix utils pack), so you have to use someone else's product. I'm a someone else, and Jnfsd is my product. As java is cross platform you can use it on any OS that runs a full Java runtime environment, not just Windows.

Why did I write jnfsd? I wanted some way adding some storage space to a unix box at home from a Windows 98 box (samba's excellent, but works the other way around). Like most other people would I tried a few search engines for NFS and although I got a lot of hits, all (that I found) were either not free, or didn't actually provide a full read write NFSD. Try searching for yourself and see if you have better luck than I did. Thanks to remotetea it took about 2 days part time to write, then another 2 days trying (and not succeeding) to come up with a better solution for the rename problem. It hasn't been revised to cure any of it's problems or to be tidied up, and I probably won't do any more work on it unless there's a good reason to.

Why am I giving it/the source away? It was simple to write and has a number of issues which means it falls short of any other NFS server I've seen. If you're at all interested in Java, and need something like this then download the source, see how simple it is to write, then write something better.

JNFSD is ENTIRELY thanks to RemoteTea - an ONCRPC implementation for Java. BTW - thanks to remotetea's creator Harald Albrecht for the supportive email!

NOTE that nfsserver.jar contains the oncrpc library from remotetea, so if you're worried about licensing, read remote tea's GPL statement.

JNFSD's free! Go nuts with it.

JNFSD was written for general use at home. If I get any email saying it did anything bad I'll claim that someone else wrote it then ran away. Just see if I don't.

Note - while the word 'mount' is used frequently on this page, the Popeye & Olive joke is not.

• It's free (but check the license).
• It works.
• It's an NFSD and a MOUNTD in one.
• It's actually pretty fast on the machines I've tried.
• It's 100% run anywhere JAVA - run it on Linux, or run it on Windows - it doesn't care. Simple.
• Easy to install and run. Install Java runtime environment, then run 'java -jar nfsserver.jar'
• Seen running on/between Windows98, Linux, Windows 2000 and Solaris.

• The concept of idempodent operations isn't implemented. What does this mean? Well on a 'real' NFS server, some operations (such as create) are only performed once for a particular request - if a particular request is resubmitted then the server should just return the status of the operation, not retry the command. This doesn't mean for example that for 2 write requests for the same block of the same file the second block shouldn't be performed, it just means if that request is the same request the second write shouldn't be performed. This is usually achieved by looking at a request number in the structure passed to the RPC server function by the dispatcher routine: there's probably a way of looking for this in remotetea, but I didn't find it after a short look, so didn't bother. What this will mean is that if you perform a UDP mount and your mount has a short time-out period you may get some spurious errors. If you're worried about this specify a long time-out period when typing the mount command on the client.
• It's heavy on memory requirements for large filesystems. The method I used for storing file handles is very simple - every time the client requires a handle for a file, I generate one and store the handle and the complete filename (including path) in a table. Not only this, but I store both the handle and the filename twice. I found that doing a recursive sum on the client's mountpoint for a filesystem with about 5000 files (a windows 2000 machine), the server was using up around 15 meg of memory. Note - this memory usage is once only for each file handle. I.e. performing the same sum twice won't use any more memory.
• Filesystem details are incorrect. Information returned to the client about amount of free space, used space, etc. are fixed and incorrect. The reason? Java doesn't have a statfs. One solution would be to operate some native code on the machine via a dynamic library, or execute a binary depending on the detected OS type, but that wouldn't really be JAVA now would it? :O)
• File permissions are incorrect. The server works on the following: if a file or directory is writable (by JNFSD), then the mode returned is "-wx-wx-wx", if the file or directory is readable, the mode returned is "r-wr-xr-w" (and the two are ORed together if the file / directory is both). Again, this is due to limitations in Java.
• Unmounting a filesystem clears down the file handle table for all mounts. I.e. if the same server has C: mounted on the network, and D: mounted on the network, then C: is unmounted on the client, the D: mount will get a few "Stale NFS handle" errors.
• At the moment, all root filesystems are exported by the mountd. I.e. If you run this on a windows machine all of your drive letters can be mounted remotely, or on a unix machine remote clients can mount '/'. This would be easily fixed in the server but I can't be arsed. The source is here if you want to change this yourself.
• Doesn't comprehend sym links if your server filesystem supports them.
• Only supports NFS v2.
• The mountd only provides mount and unmount functionality.

Ok, you've downloaded it, you've designated a machine to be the NFS server and you have a machine that can perform NFS mounts. Now what the hell do you do? If you've got the java runtime environment installed, a portmapper running and no existing nfsd/mountd, then just run 'java -jar nfsserver.jar'. Otherwise, here's a checklist:

1. Download nfsserver.jar and put it somewhere on the server machine.
2. Download the latest Java runtime environment for free, then install it.
3. If you haven't got a portmapper installed on the server: get one. For Windows, download one free. Note windows 2000 has its own, portmap.exe is for NT, pm_ascii.exe works for 98. Install and run the portmapper.
4. If you're running a server that already runs a nfsd and or mountd: disable them. For unix this usually means either disabling whatever starts them up in /etc/rc*.d/*, or by editing /etc/inetd.conf to stop inetd starting them up.
5. Run 'java -jar nfsserver.jar' on your server.
6. On the client, check all is well by running 'rpcinfo -p the_nfs_server' (where the_nfs_server is er... the name or IP of nfs server) - you should see a tcp and udp entry both for mountd version1, and nfs version 2.
7. On the client, do the mount. The export is a single letter which is the same as the single letter of any root filesystem on the server. For example: The C drive of a windows machine could be mounted with 'mount the_nfs_server:C /mntpt', or the root of a Linux machine mounted with 'mount the_nfs_server:/ /mntpt'.
8. Hammer the server by running something like: 'find /mntpt -type f -exec sum {} \;' to check it works.
9. Don't forget in windows, a jar is associated with javaw - just double click on your portmapper, double click on nfsserver.jar and you're done.

Want to build the source but don't know how? Here's a checklist:

1. Download the source, unzip it.
2. Download the latest Java development environment for free, then install it.
3. Download the superb remotetea for java.
4. Run make with either 'Makefile' for unix or 'Makefile.win' for windows. Note Makefile.win doesn't generate the .jar file properly - it's a manifest problem that I haven't looked into. Also, it doesn't correct the port number for nfsd to 2049 (which actually won't matter for most NFS clients as they use the portmapper - read Makefile.win for more information).
5. If you don't have a make utility: copy oncrpc.jar and jrpcgen.jar from the classes directory of the remotetea installation into the same directory as the unzipped source, then type:

   java -jar jrpcgen.jar -s mount_absserver mount.x

   java -jar jrpcgen.jar -s nfs_absserver nfs_prot.x

   *

   javac -classpath oncrpc.jar;. mainline.java

   java -classpath oncrpc.jar;. mainline

   * - At this point you could hand edit nfs_absserver.java to change the lines:

   FROM:

OncRpcUdpServerTransport(this, 0, nfs_prot.NFS_PROGRAM, 2, 32768), OncRpcTcpServerTransport(this, 0, nfs_prot.NFS_PROGRAM, 2, 32768),

TO:

OncRpcUdpServerTransport(this, 2049, nfs_prot.NFS_PROGRAM, 2, 32768), OncRpcTcpServerTransport(this, 2049, nfs_prot.NFS_PROGRAM, 2, 32768),

If you don't change the port number to 2049, some nfs clients will not communicate with jnfsd as they don't use the portmapper. Most clients do use the portmapper however, so this won't be necessary. Whatever works for you.

A few comments about the source:

• The nfs_misc functions free up room in the nfs_server source file. All the functions are static as the constructor of nfs_server never returns (and therefore no good places to state a constructor or pass a constructor into the nfs_server).
• There's no consideration for locking.
• The nfs_fh (the 32 byte file handle passed around) is either 'rt:<root>' from the mountd, or a 4 byte integer cast into a byte array.
• Besides some basic tidying up, no effort has been made to make this source more modular or clean. It's short, messy and simple. Like my cat.
• The print line of the report routine in nfs_misc is commented out in the downloadable jar.
• The makefiles don't bother deleting the clients as they're handy now and then for debugging.

1. Download the latest Java development environment for free, then install it.
2. Download the superb remotetea for java.
3. Find a unix box, copy any '.x' file (usually from /usr/include rpcsvc) or write your own.
4. Run: java -jar jrpcgen.jar <your X file>
5. If you get errors, try changing a few of the types - e.g. unsigned to u_int.
6. If all's well you should now have a client and server. Want your client / server to talk to a client / server written in a native language like 'C'? Run your OS's 'rpcgen -a <your X file>' (or download and rpcgen executable if you haven't got one installed), and you'll now have a matching client / server in 'C'. Mix and match e.g. the java client with the 'C' server and away you go - java RPC without RMI, CORBA, etc. Albeit without any 'object orientatedness'. Again, remotetea is very, very cool. I'll write and post a step by step tutorial on writing e.g. a server in C and a client in Java if anyone asks for it.

Firstly, read the license and the disclaimer.

jnfsd

jnfsd source

It's great that people are spending time and messing around with this stuff, but I just can't be arsed to try this stuff out right now. I'm a married guy, so my weekends comprise of walking around DIY centres, and looking interested while contemplating driveway paving, I'm too busy for owt else.

However, it'd be a crime (not an exciting crime like stealing from a bank, but a stightly dull crime like putting out a cigar in a short man's hat) to just leave this stuff by the wayside when people have put some effort into it, so I'll just forward any modifications here and leave the original page and source as is. If you email me a mod and don't want part of the email included, let me know.

Bernhard Fastenrath's virtual java desktop project: http://javadesktop.sourceforge.net/

Here's an email from David Budworth:

Hello, My name is David Budworth, and I started playing with JNFSD today.

I just wanted to let you know, that the current version of ONCRPC does not auto start it's services

That may not be the correct terminology, but I found that I had to do: new nfs_server().run(); new mount_server().run(); in order for the NFS server to register itself. This may be because I integrated jportmap and jnfsd into one app.

I'm attaching my revised version of "mainline.java".

Aside from the format change (Sorry, I had a hard time following the code with it's indent style, so I reformatted it all), I added the following:

1) Check for running portmap

2) If portmap isn't running, start remotetea's jportmap server.

3) Added "new xxx_server().run" to the startup threads.

Actually, I nuked your mainline.java thread code, and added back different stuff. Originally, I saw that when you do "new xxx_server()" that those constructors return, so I took out the thread code.

I hadn't realized that they weren't actually starting. So, anywho, Here's my little contribution to the cause.

Thank you, -David

Dave Brand is using JNFSD with his Rio Receiver (how cool is that?). He did find a couple of issues, so here's his description of the source revisions. Note - there are a couple of OS specific lines (e.g. fully qualified pathnames starting with "/"). If there are any more worthwhile mods I may start releasing diff patches instead.

Here you go. There are 2 bug fixes:

1. In nfs_server, we will now return only as many bytes as were requested.

2. In nfs_misc, I fixed the calculation of the number of blocks.

The "enhancements" I added were:

1. It will first look for the directory to mount in the current directory, eg. mounting "/usr" will first look in "usr" in the current directory. It was a quick and simple way to allow names other than drive letters. It really wouldn't be hard to add an alias file (eg. export d:\windows as /windows) but this was good enough for me. The old drive letter stuff will still be used if the current directory doesn't contain the mount.

2. It will treat any files in directories named "dev" as special files. Right now, only block and character special files are supported. I started on symbolic links but stopped when I realized I didn't need them. Feel free to finish it up.