samba - Feb 2023 - Missing Files/Missing Folders from an NFS Share

Just by way of update on this, it looks like the problem exists with the
ReadDir, TellDir and SeekDir implementation on NFS shares.  In my case it
was an AWS EFS share that uses NFS.

The fix in the samba code isn't straightforward.  As a workaround on my
case I discovered that if I mount the NFS share at say /mnt/mountpoint1 and
the use sshfs to connect back into the same machine and mount at
/mnt/mountpoint2 the /mnt/mountpoint1 directory I can then share the
/mnt/mountpoint2 share with Samba and the sshfs layer that sits between
Samba and the NFS mount seems to correct the issues that are present if t
the mounted NFS share were shared with Samba directly.

So instead of

NFS -> /mnt/mountpoint1 and /mnt/mountpoint1 -> Samba -> Windows Client

I use

NFS -> /mnt/mountpoint1 and /mnt/mountpoint1 -> /mnt/mountpoint2 (via
sshfs) and /mnt/mountpoint2 -> Samba -> Windows Client

There is a performance hit in doing this, but it is something I can live
with.

For the record, I tried a simple passthrough FUSE mount, but couldn't get
that to work correctly.

On Fri, 17 Feb 2023 at 02:43, Jeremy Allison <jra at samba.org> wrote:
> On Fri, Feb 17, 2023 at 12:57:09AM +0100, Conor Armstrong via samba wrote:
> >Alternately, we could possibly modify the dptr_TellDir function to set
a
> >flag somewhere if it ever returns a negative offset. Then any calls to
> >dptr_SeekDir checks if the flag is set and does a slower approach of a
> >RewindDir and then multiple ReadDir & TellDir calls until we get
the
> >matching offset.  If flag is not set then go with the normal SeekDir
> call???
>
> Again, we need to understand the specific brokenness of NFS
> telldir()/seekdir()
> first. Doing a rewinddir() on every FindNext would be the death
> of performance :-(.
>

On Mon, Feb 27, 2023 at 01:18:20PM +0100, Conor Armstrong via samba
wrote:
>Just by way of update on this, it looks like the problem exists with the
>ReadDir, TellDir and SeekDir implementation on NFS shares.  In my case it
>was an AWS EFS share that uses NFS.
Can you elaborate exactly the issue with the AWS NFS server here ?
It would be really helpful to understand what it's doing here.
>The fix in the samba code isn't straightforward.  As a workaround on my
>case I discovered that if I mount the NFS share at say /mnt/mountpoint1 and
>the use sshfs to connect back into the same machine and mount at
>/mnt/mountpoint2 the /mnt/mountpoint1 directory I can then share the
>/mnt/mountpoint2 share with Samba and the sshfs layer that sits between
>Samba and the NFS mount seems to correct the issues that are present if t
>the mounted NFS share were shared with Samba directly.
>
>So instead of
>
>NFS -> /mnt/mountpoint1 and /mnt/mountpoint1 -> Samba -> Windows
Client
>
>I use
>
>NFS -> /mnt/mountpoint1 and /mnt/mountpoint1 -> /mnt/mountpoint2 (via
>sshfs) and /mnt/mountpoint2 -> Samba -> Windows Client
>
>There is a performance hit in doing this, but it is something I can live
>with.
I'm glad you found a fix, but if we can understand what is wrong
with AWS NFS here we might be able to do something more performant
in Samba.