ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Windows and NFS

    Water Closet
    4
    23
    1.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • scottalanmillerS
      scottalanmiller @brandon220
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • 1
        1337 @black3dynamite
        last edited by 1337

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

        scottalanmillerS 1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @1337
          last edited by

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

          1 1 Reply Last reply Reply Quote 0
          • 1
            1337 @scottalanmiller
            last edited by 1337

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

            1 scottalanmillerS 2 Replies Last reply Reply Quote 0
            • 1
              1337 @1337
              last edited by

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

              1 1 Reply Last reply Reply Quote 0
              • 1
                1337 @1337
                last edited by 1337

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

                brandon220B 1 Reply Last reply Reply Quote 0
                • brandon220B
                  brandon220 @1337
                  last edited by

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

                  scottalanmillerS 1 Reply Last reply Reply Quote 0
                  • scottalanmillerS
                    scottalanmiller @1337
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • scottalanmillerS
                      scottalanmiller @brandon220
                      last edited by

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

                      1 1 Reply Last reply Reply Quote 0
                      • 1
                        1337 @scottalanmiller
                        last edited by

                        @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

                        scottalanmillerS 1 Reply Last reply Reply Quote 0
                        • scottalanmillerS
                          scottalanmiller @1337
                          last edited by

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

                          1 1 Reply Last reply Reply Quote 0
                          • scottalanmillerS
                            scottalanmiller
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • scottalanmillerS
                              scottalanmiller
                              last edited by

                              Big vendors like NetApp and Synology allow you to put both protocols on the same share. So that's a good sign, as well.

                              brandon220B 1 Reply Last reply Reply Quote 1
                              • brandon220B
                                brandon220 @scottalanmiller
                                last edited by

                                @scottalanmiller This is true. I forgot about my ReadyNAS units allowing multiple protocols.

                                scottalanmillerS 1 Reply Last reply Reply Quote 0
                                • scottalanmillerS
                                  scottalanmiller @brandon220
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • 1
                                    1337 @scottalanmiller
                                    last edited by 1337

                                    @scottalanmiller said in Windows and NFS:

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

                                    Just that comparing windows and *nix you see that there are different file locking mechanisms in play. That is what could cause corruption. Samba has to support Windows mechanisms while it's file system is residing on unix.

                                    For instance from Samba 3.0 documentation (for historical context only):

                                    Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. This cannot be fully correct for several reasons. The simplest is that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.

                                    Samba 2.2 and above implement record locking completely independently of the underlying UNIX system. If a byte-range lock that the client requests happens to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. No other locks can be seen by UNIX, anyway.

                                    scottalanmillerS 1 Reply Last reply Reply Quote 0
                                    • scottalanmillerS
                                      scottalanmiller @1337
                                      last edited by

                                      @Pete-S said in Windows and NFS:

                                      @scottalanmiller said in Windows and NFS:

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

                                      Just that comparing windows and *nix you see that there are different file locking mechanisms in play. That is what could cause corruption. Samba has to support Windows mechanisms while it's file system is residing on unix.

                                      For instance from Samba 3.0 documentation (for historical context only):

                                      Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. This cannot be fully correct for several reasons. The simplest is that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.

                                      Samba 2.2 and above implement record locking completely independently of the underlying UNIX system. If a byte-range lock that the client requests happens to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. No other locks can be seen by UNIX, anyway.

                                      That's very complex. But it sounds like Samba is just... not locking the file and hoping for the best?

                                      1 Reply Last reply Reply Quote 0
                                      • 1
                                      • 2
                                      • 1 / 2
                                      • First post
                                        Last post