linux-nfs / nfsd

Linux kernel source tree
Other
0 stars 0 forks source link

NFS and Samba interoperability #26

Open chucklever opened 7 months ago

chucklever commented 7 months ago

This was bugzilla.linux-nfs.org 227

[Ricky Nelson 2012-07-10 07:58:16 UTC] This BZ is to request upstream development to support exporting directories via NFS and Samba simultaneously. In reality this is under kernel, nfs-utils, and samba.

There are a vast number of environments where this is already being done, but this is currently not a supported configuration through either NFS or Samba. The main reason that comes to my mind is because of the use of different locking systems. NFS uses BSD style locks (flock) and Samba uses POSIX locks (fcntl). The 'flock' and 'fcntl' locking systems do not communicate with each other.

For example, if NFS takes out an exclusive-write flock on a file (because an NFS client is making a change to that file), Samba could then read from, write to, or even delete the file while NFS expects the file to be exclusively locked.

The reverse could happen as well where Samba could exclusive lock a file and NFS could come along and read, write, or even delete that file. The end result would likely be file corruption.

Discussing this with others, additional complications can arise from Windows and Linux utilizing different types of ACLs.

Thanks in advance for insight into this.

chucklever commented 7 months ago

[Trond Myklebust 2012-07-10 09:34:39 UTC] This isn't client related at all. Changing component to 'server' and reassigning to Bruce...

That said, the request seems a bit confused.

IIRC, Samba does also support POSIX locks as part of the 'UNIX compatibility' mode. Those are generally used by Linux CIFS clients when running POSIX applications, and should therefore be 100% compatible with Linux NFS clients, which also support POSIX locks.

Samba also uses BSD locks so that it can implement Window-style "share locks", which are a type of mandatory lock that is set on open() of the file by Windows SMB clients. Since NFSv2/v3 is stateless, there is no equivalent of share locks that those clients can use.

NFSv4, however, is stateful, and supports Windows share locks as part of the OPEN operation. We could change the Linux NFS server to use BSD flock locks in order to implement them, and that would make NFS and Samba work "correctly" as far as a Windows environment is concerned.

chucklever commented 7 months ago

[J. Bruce Fields 2012-07-10 11:17:35 UTC] Jeff Layton has been looking into share lock implementation. There's a ton of work to be done in the area of NFS/Samba interoperability.

chucklever commented 7 months ago

[J. Bruce Fields 2022-01-08 21:15:37 UTC] Off the top of my head, other possible areas of improvement for SMB/NFS service interoperability:

May also want to look into collaboration with maintainers of new in-kernel SMB server; with both servers in-kernel, it might be simpler to develop common mechanisms (which could then be exposed to userspace once they're working?). Other possible collaborators are SMB and Ganesha developers.

There's lots of interest but none of these projects are small and nobody is working on them actively. Don't know if this is the best place to track this; reassigning to Chuck for him to decide....

chucklever commented 7 months ago

[Chuck Lever 2022-01-21 19:26:00 UTC] This comes up at the regular LSF summits.

We need to find someone who can explain the current pain points to understand what we should be doing to make this a premier feature. The locking issues will require VFS changes. ACL interoperation is a minefield that has already had many years sunk into it without a lot of positive results. We are not familiar with the ID mapping issues.

Leaving this parked here -- if more information becomes available we can restart the discussion.

chucklever commented 7 months ago

It would help if someone familiar with Samba and NFSD could start breaking this issue into smaller tasks, and outline some steps to address each task. Bruce mentioned the basic categories above, and there are likely a few more.