samba - Jun 2024 - Random permission denied and path not found errors

On 6/17/24 20:18, Rowland Penny via samba wrote:
> There have been numerous fixes since 4.15.x , using the most recent
> version of Samba possible is always a good idea.

As usual, my concern with new releases that even though some fixes are 
included in general, with new features new bugs are added too.

Of course, if nobody comes up with a specific idea or suggestion, I will 
give it a try.


Is there anybody on the list, who is familiar with a similar use case: a 
VFX workload backend or a storage server with a (relatively) lot of 
files and parallel clients (read and write) and about 1-4 Gb/s traffic load?

I have never maintained Samba server in such an environment before and I 
have never met a similar issue before. I would like to make sure whether 
Samba is suitable to serve a specific workload like this.
> Hmm, did you take the standard Ubuntu smb.conf and then add to it ?

Yes, I did.

> I ask this because you have numerous lines that do not really have a
> place in Unix domain member smb.conf
>
> I would definitely remove these lines:
>
>   ?? ?obey pam restrictions = Yes
>   ?? ?pam password change = Yes
>   ?? ?passwd chat = *Enter\snew\s*\spassword:*  %n\n
*Retype\snew\s*\spassword:*  %n\n *password\supdated\ssuccessfully* .
>   ?? ?passwd program = /usr/bin/passwd %u
>   ?? ?server role = standalone server
>   ?? ?unix password sync = Yes
>
> Unless you have 'guest ok = yes' or 'public = yes' set in a
share (if
> so why ?) then I would remove this line:
>
>   ?? ?map to guest = Bad User
>
> Also if you are not going to be using usershares, I would remove this
> line:
>
>   ?? ?usershare allow guests = Yes

To my understanding, the above settings are unrelated to my problem. 
Correct me, if I'm wrong.
> Turning to your share, add these lines to 'global':
>
>    vfs objects = acl_xattr
>    map acl inherit = Yes
>
> then make your share look like this:
>
> [HUNY_asset]
>   ?? ?comment = HUNY/asset
>   ?? ?read only = No

According to man page:

read only (S)

 ?????????? An inverted synonym is writeable.

Does it make any difference compared to 'writeable = yes'?

> Then read this:
>
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs

Since my FS backend is ZFS, my guess is that it should be vfs_zfsacl.

But actually don't really want to complicate the rights. I would like to 
use the standard posix mode right management. Is my assumption correct 
that in such a case I don't need the above ACL settings?

Currently, my problem solely related to the random permission denied and 
path not found errors which regularly come and go so I don't think, it's
really a right problem.


Thanks,


t

On 6/17/24 22:46, Tamas Papp via samba wrote:
> Is there anybody on the list, who is familiar with a similar use case: a 
> VFX workload backend or a storage server with a (relatively) lot of 
> files and parallel clients (read and write) and about 1-4 Gb/s traffic 
> load?
Hello.

I'm not even sure I know what you mean by "VFX workload" exactly.
However the problem you describe looks a lot like the one I see with a 
"developer's" workload (i.e. compiling on a client while accessing
source/headers on a Samba server, which also means opening thousands of 
small files).
Sometimes compilation will fail on the claim that some file does not 
exist: the file is there and a subsequent retry will succeed.
What I noticed is that more (Samba unrelated) load on the server will 
make this a lot more likely.
I.e. run a compilation on the client when the server is idle and it will 
almost always succeed; run a completely unrelated compilation on the 
server (on files not involved in the client compilation) and the client 
will almost always fail.
I've not been able to debug this yet (although it's been going on 
possibly for years).

Please also read my latest thread ("Samba suddenly acting strangely?")
where this is one of the problems I was talking about.

Unfortunately, I've really nothing to suggest to you right now, but I 
hope we can keep in touch in case one of us finds something interesting.

  bye & Thanks
	av.