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

On Wed, Feb 15, 2023 at 08:06:28PM +0100, Conor Armstrong
wrote:
>   Rowland & Jeremy - thanks for this!
>   I built a copy of the latest version from github 4.19 and same issue
>   arises. ?
>   I will have a look at the wireshark trace and see if I can spot anything
>   obvious there.
>   I'm not an expert on this, but as far?as I know NFS isn't fully
POSIX
>   compliant.? I'm not sure what is different/missing and whether that
is
>   causing the issue.? There must be some calls somewhere that are returning
>   different results from mounted local/block storage compared to a mounted
>   NFS share.
>   Running Samba on the server isn't an option for me as the share as it
is
>   Amazon EFS.
>   Strange that smbclient sees all the files but the windows?10 client
>   doesn't.? I would have thought they interact similarly?with smbd.
What smbclient ls command do you use ? If it's just

smbclient -c "ls" then we're doing a wildcard match of
"*",
which means return all files.

Could the Windows client be looking for a specific filename
pattern match ?

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 :-).
>
>