Weird inconsistency between different SMB shares

[n3mmr]

I had some problems with one of my SMB shares where you’d get Destination Folder access denied and/or You need permission to perform that action, all on just one of my several SMB shares when accessing from my Windows 11 Pro client.
My TrueNAS is CORE 13.3

So I set about copying all the settings on the working shares and their datasets to the troublesome share.

This included changing owner and group to nobody and nogroup, and doing the recursive updates from the edit acl screens.

Now when I try to access the previously troublesome share it is not even accessible!

I get a panel saying

"
\BOXPLAY\cifs is not accessible. You might not have permission to use this network resource. Contact the administrator to find out if you have access permissions.

A device attached to the system is not functioning.
"

The other shares work very well.

I cannot find ANY differences in any of the TrueNAS config panels between the working shares+datasets and the nonworking share+dataset…

But there must be some difference, I guess.

I could have missed something, of course, but I cannot find the mistake.
And there might be some properties that are less than obvious or not directly available in the config GUI.

Please suggest what might have gone wrong!

EDIT: I got this error in a powershell on the W11 Pro client
"
net use * \Boxplay\cifs *
Type the password for \Boxplay\cifs:
System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
"

[n3mmr]

I tried this from Linux Mint 22 and looked at Network in the file mgr, nemo(??), and got several choices.
“Boxplay (login)” which worked OK as in everything was available after I presented full credentials, and a more automatic view (called file share??) which behaved as the W11 client i e one share refused to connect, with “invalid argument” as the error and the other shares worked perfectly.
Just a little added data…

[n3mmr]

I created a new share, differently named but using the same dataset and exactly the same setup options and permissions/ACL

That share could be accessed, but I got again the
weird experience of not being able to actually write any content into a newly created file and most, probably all, of the directories having the “Read-only (only applies to files in folder)” Attribute.
Which I can’t seem to change!

[Johnny_Fartpants]

Hi,

Can you share screenshots of your dataset ACL and did you make any changes to the default share ACL?

[n3mmr]

No changes to the default share ACL.
Dataset ACL below. Two images since too large for one browser page.

[Johnny_Fartpants]

Personally I leave user and group alone so root and wheel. I’d then remove the everyone@ group@ and user@ and just have one entry for my user or group. I find this gives best results.

[n3mmr]

The User entry wasn’t there at first, it appeared after I mounted this share from a powershell terminal using

net use /persistent:yes
net use * \\server\sharename *

And after that it hasn’t given me any grief, at least not yet.
I can copy files with content from the local disks of the w11 box into this share.

I’m now waiting for things to break down… or not. In the latter case I will consider myself happy and let things be until I get to the point where I build a new NAS with NVMe SSDs.