Windows and NFS
-
@brandon220 said in Windows and NFS:
I thought about using samba but have read that it’s not good to use nfs and samba on the same shared folders. I prefer to keep nfs because of the efficiency on my Linux clients.
Create a new shared folder where both NFS and Samba is sharing to test.
-
@brandon220 take a look at this blog site about sharing the same data from Samba and NFS.
https://lukas.zapletalovi.com/2020/01/samba-and-nfs-shared-folder-on-centos8.html
-
@black3dynamite I know it can be done... I have read conflicting documents and articles where it goes both ways. Some say there is a risk of both systems accessing the same file via different protocols and causing corruption. I will most likely try it.
-
@brandon220 said in Windows and NFS:
@black3dynamite I know it can be done... I have read conflicting documents and articles where it goes both ways. Some say there is a risk of both systems accessing the same file via different protocols and causing corruption. I will most likely try it.
Yeah, I’m not sure about the corruption part. Maybe it’s something do with a specific samba and nfs version, filesystem that was in use, and SELinux.
-
@brandon220 said in Windows and NFS:
Why would MS implement NFS if it is so painfully slow.
Because they've always done this. They can claim that they provide support for it, but they don't make it work correctly. Apple has long done something similar.
-
@brandon220 said in Windows and NFS:
@black3dynamite I know it can be done... I have read conflicting documents and articles where it goes both ways. Some say there is a risk of both systems accessing the same file via different protocols and causing corruption. I will most likely try it.
Access to the file is always handled by the filesystem, whoever claimed that Samba and NFS can't both access the same file can't understand basic computing. By that logic, accessing one text document by Word or Notepad would corrupt it. Clearly, that's not how it works.
-
@black3dynamite said in Windows and NFS:
@brandon220 said in Windows and NFS:
@black3dynamite I know it can be done... I have read conflicting documents and articles where it goes both ways. Some say there is a risk of both systems accessing the same file via different protocols and causing corruption. I will most likely try it.
Yeah, I’m not sure about the corruption part. Maybe it’s something do with a specific samba and nfs version, filesystem that was in use, and SELinux.
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Samba would anyway have to support and keep track of these locks and only pass the compatible file locks to the underlying OS. As long as everything was accessed through Samba everything was good but if you had both NFS and Samba accessing the same file you could get corruption. Simply because Samba could have some kind of lock on part of a file that the OS didn't know about.
I think NFS also had a buggy implementation of file locking in general.
If any of this is true today I don't know. It seems unlikely though.
-
@Pete-S said in Windows and NFS:
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Those are filesystem functions, though. They happen before Samba or NFS has a chance to access the files. Unless the issue is something like one or the other not honoring the locks and using a cached copy and writing back from that, but only some portions of the file?
-
@scottalanmiller said in Windows and NFS:
@Pete-S said in Windows and NFS:
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Those are filesystem functions, though. They happen before Samba or NFS has a chance to access the files. Unless the issue is something like one or the other not honoring the locks and using a cached copy and writing back from that, but only some portions of the file?
The smb client will request a lock on a file or part of it (record locking) to Samba. When unix doesn't have an equivalent way of locking the file, the file locking happens in Samba only and not on the Samba host's filesystem where the file resides.
-
@Pete-S said in Windows and NFS:
@scottalanmiller said in Windows and NFS:
@Pete-S said in Windows and NFS:
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Those are filesystem functions, though. They happen before Samba or NFS has a chance to access the files. Unless the issue is something like one or the other not honoring the locks and using a cached copy and writing back from that, but only some portions of the file?
The smb client will request a lock on a file or part of it (record locking) to Samba. When unix doesn't have an equivalent way of locking the file, the file locking happens in Samba only and not on the Samba host's filesystem where the file resides.
Looking at the link below it seems like byte-range locking (record locking) in NFS wasn't introduced until NFSv4 and NFSv2 and v3 were stateless protocols and as such couldn't do mandatory locking.
http://nfs.sourceforge.net/So I'm guessing that Samba and NFS prior to v4 couldn't coexist without the possibility of file corruption.
-
@Pete-S said in Windows and NFS:
@Pete-S said in Windows and NFS:
@scottalanmiller said in Windows and NFS:
@Pete-S said in Windows and NFS:
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Those are filesystem functions, though. They happen before Samba or NFS has a chance to access the files. Unless the issue is something like one or the other not honoring the locks and using a cached copy and writing back from that, but only some portions of the file?
The smb client will request a lock on a file or part of it (record locking) to Samba. When unix doesn't have an equivalent way of locking the file, the file locking happens in Samba only and not on the Samba host's filesystem where the file resides.
Looking at the link below it seems like byte-range locking (record locking) in NFS wasn't introduced until NFSv4 and NFSv2 and v3 were stateless protocols and as such couldn't do mandatory locking.
http://nfs.sourceforge.net/So I'm guessing that Samba and NFS prior to v4 couldn't coexist without the possibility of file corruption.
To be honest I haven't spent much exploring this in the past because in most cases we would just use Samba for everything in mixed environments.
So maybe there are other reasons to avoid NFS and Samba on the same files but file locking is what I remember being an issue.
-
@Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.
-
@Pete-S said in Windows and NFS:
@scottalanmiller said in Windows and NFS:
@Pete-S said in Windows and NFS:
It had to do with different file locking mechanisms in NT and unix. In the windows world you could do different kind of file locking that didn't have an equivalent in the unix world. I think one of the areas of incompatibility was opportunistic file locking and also that windows could lock larger regions of a file than unix.
Those are filesystem functions, though. They happen before Samba or NFS has a chance to access the files. Unless the issue is something like one or the other not honoring the locks and using a cached copy and writing back from that, but only some portions of the file?
The smb client will request a lock on a file or part of it (record locking) to Samba. When unix doesn't have an equivalent way of locking the file, the file locking happens in Samba only and not on the Samba host's filesystem where the file resides.
That, to me, sounds like a bug in Samba (or the SMB protocol) if it corrupts a file. That mechanism should work fine and not write garbage to a file when it releases the lock. You can definitely do that for performance, which is great, and either fully lock the underlying file from other processes (keeping NFS from writing at all) or leaving it unlocked and writing the fully changed document back. In either case, the file doesn't corrupt. One overwrites the other, but that's always the case with a cache.
-
@brandon220 said in Windows and NFS:
@Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.
There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.
-
@scottalanmiller said in Windows and NFS:
@brandon220 said in Windows and NFS:
@Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.
There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.
That is an incorrect assumption. Read this: https://en.wikipedia.org/wiki/File_locking
-
@Pete-S said in Windows and NFS:
@scottalanmiller said in Windows and NFS:
@brandon220 said in Windows and NFS:
@Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.
There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.
That is an incorrect assumption. Read this: https://en.wikipedia.org/wiki/File_locking
Which part? I read the part of NFS, but that doesn't seem to apply. That would cause problems, but not corruption problems, right?
-
https://www.itprotoday.com/windows-78/sharing-same-folder-nfs-and-smb
"There's no restriction on the folders pointed to by the SMB or NFS share. Both SMB and NFS are file-based sharing protocols and allow access to the data stored within the folder and subfolders the share points to.
These protocols don't change the underlying file system. Thus, having multiple shares, even different protocol shares, that point to the same base folder isn't a problem."
-
Big vendors like NetApp and Synology allow you to put both protocols on the same share. So that's a good sign, as well.
-
@scottalanmiller This is true. I forgot about my ReadyNAS units allowing multiple protocols.
-
@brandon220 said in Windows and NFS:
@scottalanmiller This is true. I forgot about my ReadyNAS units allowing multiple protocols.
I thought that they did too. Most everyone does, and nearly everyone uses Samba under the hood.
