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

I'm trying to get to the bottom of where the normal directory functions
differ in results for block storage compared to NFS.

I created a short c script to look at the offsets generated for the
directory when block storage backed in comparison to NFS backed.

block storage backed are always positive:

File: 5050, Offset: 9213006461214587617

File: 6567, Offset: 9218690536865144001

File: 4033, Offset: 9220247894244709239

...

NFS backed are negative:

File: 2535, Offset: -376809161603969956

File: 4236, Offset: -376809161586095012

File: 3507, Offset: -376809161585570724

...

The negative NFS negative offsets seem to be managed already
in source3/smbd/dir.c in the map_dir_offset_to_wire() function which
adjusts for signed/unsigned longs.

You mention that NFS doesn't have a working seekdir()/telldir()/rewinddir().
Other than the different offset (cookie) management, do you know of any
other differences?

I had a look at the wireshark dumps. I'm getting a STATUS_PENDING shortly
followed by a STATUS_CANCELLED for the NFS share which are absent on the
block storage share.

> On Wed, Feb 15, 2023 at 08:28:47PM +0000, Rowland Penny via samba wrote:
> >>>>>>*NFS has no real idea about user authentication and
uses
> *>>>*ipaddresses,
> *>>>>*True for NFSv3, not for NFSv4.
> *>>*But then wont it be using NFSv4acls ?
> *
> This is authentication, not authorization. NFSv4 can be configured
> to use krb5 auth, so then it's not ipaddess based and is as secure
> as Samba for initial connection and can be as secure as SMB3
> (signing, sealing etc).
>
> >>>*in other words, you are going to have problems, at least I did
> *>>>*when I tried it once. It may be different now, but I doubt
it. If
> *>>>*you are going to share an nfs share, just do it with nfs.
> *>>>>*Good advice, but mostly because NFS doesn't map
completely to
> *>>*POSIX semantics, and it also means the data goes over the
> *>>*wire twice. Having said that, sometimes people need to do
> *>>*this (the Amazon NFS user is a case in point) so we should
> *>>*track down and help fix the problems when we can.
> *>>*I can understanding helping people when we have to, but I still
think
> *>*the best first help should be 'do not do that', closely
followed by
> *>*'upgrade Samba' :-D
> *
> Well Ralph just pointed out that NFS doesn't have a working
> seekdir()/telldir()/rewinddir() which means that working code
> that depends on this.... won't (work over NFS that is :-).
>
> Always try and help people first, only later say "don't do
> that". People always have a reason to be doing what they're
> doing, even if we don't agree with it.
>
> You can tell 'em you don't agree with what they're doing
> without being judgemental :-).
>
>

On Thu, Feb 16, 2023 at 08:46:26PM +0100, Conor Armstrong
wrote:
>   I'm trying to get to the?bottom of where the normal directory
functions
>   differ in results for block storage compared to NFS.?
>   I created a short c script to look at the offsets generated for the
>   directory when block storage backed in comparison to NFS backed.?
>   block storage backed are always positive:
>
>   File: 5050, Offset: 9213006461214587617
>
>   File: 6567, Offset: 9218690536865144001
>
>   File: 4033, Offset: 9220247894244709239
>
>   ...
>
>   NFS backed are negative:
>
>   File: 2535, Offset: -376809161603969956
>
>   File: 4236, Offset: -376809161586095012
>
>   File: 3507, Offset: -376809161585570724
>
>   ...
>
>   The negative NFS negative offsets seem to be managed already
>   in?source3/smbd/dir.c in the?map_dir_offset_to_wire() function which
>   adjusts for signed/unsigned longs.
>   You mention that?NFS doesn't have a working
>   seekdir()/telldir()/rewinddir(). Other than the different offset (cookie)
>   management, do you know of any other differences?
>   I had a look at the wireshark dumps. I'm getting a STATUS_PENDING
shortly
>   followed by a STATUS_CANCELLED for the NFS share which are absent on the
>   block storage share.
Samba relies on being able to do offset = telldir() and then
seekdir(offset) returning us to the same position in the
directory listing.

If you think about this you'll see why. Imaginary case,
directory with files a-z. Client does findfirst with 1k
buffer, server enumerates files one by one, but when
it gets to "m" it finds it doesn't have enough room
to marshall the client response.

No worries, we saved off the 'offset = telldir()' before
doing the readdir that returned filename "m". So we
seek back to the offset before the filename "m" in
this code:

         if (NT_STATUS_EQUAL(status, STATUS_MORE_ENTRIES)) {
                 dptr_SeekDir(dirptr, prev_dirpos);
                 return status;
         }

and return the findfirst reply with files a-l.

Now when the listing continues, it'll do so with
filename "m" etc. until the listing is done.

If:

offset = telldir()
seekdir(offset)

doesn't return us to the same position in the directory
listing, then we are broken and will not return the complete
list of files.

This is what Ralph is saying when he says that NFS is
broken w.r.t listing directories. What NFS server are
you using ?

This looks relevent:

https://lore.kernel.org/all/CAAmbk-e-YQAPo6QyNB0aJyc9qzUShmEC+x5eTR7wqp1ABWADsg
at mail.gmail.com/T/

Client then does findnext,