search

dCache / nfs4j

Pure Java NFSv3 and NFSv4.2 implementation
Other
240 stars 76 forks source link

Running server on Windows #64

Closed kjertil closed 4 years ago

kjertil commented 6 years ago

Hi,

I'm trying to get the NFS4J server to run on Windows. I'm using the latest code from the repository, since the released version had some issues. And I'm using the LocalFileSystem implementation from the simple-nfs project. Note: I'm the using NFS3 protocol.

My NFS client connects correctly, however it performs a number of operations, that fails on the server, most noticable wildcards *. And the request for large files.

Wildcards When running the client, I get exceptions like this on the server.

Large file support I'm uncertain as to the problem, might be related to the problem above, might be an incorrect error message from the client. However it might also be a configuration or implementation problem with the server.

error: Failed to clone disk: The destination file system does not support large files (12).

Does NFS4j support large files, and if so, how do I configure this?

Please advice

Best regards Kjertil

kofemann commented 6 years ago

java.nio.file.InvalidPathException: Illegal char <> at index 0: .vmx9IizqK at

this looks like the wildcard is passed to server. this should be resolved on the server side. Do you use simple-nfs code or you have your own implementation?

Related to large file support. nfs4j should work with files with size up-to 2^63. Bigger files is a problem due to java's signed natives. But I don't think that this is your concern, isn't it?

kjertil commented 6 years ago

Hi again,

I'm currently using a slighty modified simple-nfs code. Handling the wilcard lookup, is not a problem in it self. But returning the result is. The current interface only allows the return of an Inode object, containing a single FileHandle. How would/should one go about returning multiple FileHandles?

Related to large file support

As I wrote in my original post, this issue could just be a result of incorrect errorhandling on the client side, due to above wildcard handling. I'll investigate further, once the other issue is resolved.

Best regards Kjertil

kofemann commented 6 years ago

The LOOKUP operation can return only single file handle. This is what rfc1813 says:

Procedure LOOKUP searches a directory for a specific name and returns the file handle for the corresponding file system object. On entry, the arguments in LOOKUP3args

If you need multiple file handles, then you should use READDIR. As I already have mentioned: wildcard handling should happen on the client side.

Toilal commented 5 years ago

I have initialized a project called nfs4j-daemon to support file sharing from windows properly. It's inspired by simple-nfs repo from @kofemann, but I have fixed some issues I have encountered while testing and refactored some stuff.

My goal is to provide a good replacement for winnfsd which lacks active support, has no NFSv4.1 support and has issues with unicode characters in filenames.

It's currently tested manually with NFSv4.1 by running a npm install on the shared directory. I can't tell you if it's working properly with NFSv3, but it theorically should ...

For now, it requires the snapshot version of nfs4j and this patch. For symlinks support, you have to run it as Administrator. No README for now, sorry, but you have to create a nfs4j.yml file in cwd with at least the root property.

root: 'C:\'
Toilal commented 5 years ago

For the wildcard issue, I have implemented a try/catch on Path.resolve failures in lookup method that throws BadNameException. It seems to be the way to go according to specs, and fix the issue in my use case.

For large files, I have implemented UNSTABLE write with COMMIT that should give better performance, but I'm not sure it'll solve your problem.

Toilal commented 5 years ago

It's now released, and supports adding multiple folders to the shared FileSystem. I have some teamates now running this instead of Winnfsd, and it seems robust now.

https://github.com/Toilal/nfs4j-daemon (Checkout the README for install and configuration).

I still have to add some options, like default UID/GID used on windows (it's hardcoded to 1000/1000 inside this version).

kjertil commented 5 years ago

It's now released, and supports adding multiple folders to the shared FileSystem. I have some teamates now running this instead of Winnfsd, and it seems robust now.

Sounds great :-) Thanks!

I'm heading of on christmas vacation, but I'll try your project once I'm back again in january.

Toilal commented 5 years ago

I have just released a new version (0.4.0) that supports linux file permissions on windows server.

That means it supports chown and chmod commands as expected. Linux file permissions are stored into file databases inside .nfs4j directory of the windows user directory.

kofemann commented 4 years ago

@kjertil I am closing this issue. The https://github.com/gfi-centre-ouest/nfs4j-daemon shows that running on windows is not a problem.

Feel free to re-open it, if you think it's not solved.