Running server on Windows about nfs4j HOT 9 CLOSED

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).

from nfs4j.

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.

from nfs4j.

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?

from nfs4j.

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

from nfs4j.

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.

from nfs4j.

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:\'

from nfs4j.

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.

from nfs4j.

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.

from nfs4j.

@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.

from nfs4j.