Issues with smb and permissions on fresh install of OMV 5

I recently attempted to upgrade my omv4 I install to omv5. Things went sideways because of Plex, so I backed there data in my array up and decided to go with a fresh install of OMV5. Everything appeared to go fine. After the install, I mounted the array, created the shares, created a user account and assigned the groups and permissions. On my Windows 10 laptop I then mapped the share to a drive. I can browse the drive, but I cannot write or delete or anything other than read. Looking at the smb/cifs screen in the webui, the account is now locked and has read only access. Connecting to the share as root gives the same issue. The minute the I browse the share, regardless of account, the account gets read only and the files lock. I’ve triple checked permissions. I’ve even reinstalled omv5. I’m out of ideas. Anyone have any suggestions before I attempt a fresh install of omv4 to see if this is just a weird omv5 thing?

Here is what I see in the SMB/CIFS tab in Services when I connect to the drive share. The other odd thing about this is that it worked fine for the first 2 or 3 hours after the initial install. Once the behavior started though, it's persisted through full reinstalls of OMV 5.

The ACL on the folder has my AngryM0nk3y account with Read/Write. The sambashare and users groups also have Read\Write. Also, the AngryM0nk3y account is a member of users, root, sudo, ssh, and sambashare.

I have not done that yet. There was an issue in the initial install of OMV5 where there were several non-existent accounts that were still owners of several of the files and folders. I used chown to change the owner ship to root\users.

I have now tried resetting the acls to omv's default. Creating a new share for just the Temp folder on the array, giving my account permissions, mapping the drive, and browsing to the new drive. The same read-only issue pops up. I have installed the sharerootfs plugin to see if there was something wrong with the array. The problem persists on the root file system. I booted off a FedoraLive usb key, accessed the array, shared the array, mapped to it, and successfully copied and deleted files. It's just OMV that has an issue with the sharing of the files. I'm at a loss.

I have now verified that OMV 6 exhibits the same behavior.

The account was given the read\write permissions on the share right after I created it. It doesn't seem to care that the permissions are set for read\write. The minute I map the drive, it locks files and relegates me to RDONLY.

I installed OMV 6 last night just to see if I was running in to some sort of strange OMV 5 permissions issue. I can run install OMV 5 again, but the issue will follow me. I'll put OMV 5 back on, share the folder, create the account, and assign the permissions. I'd be willing to be money on the problem coming back up again. I'll do that and post the the cat of /etc/samba/smb.conf.

The array is a RAID 10 of 4 3TB WD REDS. I ran SMART short tests of all 4 drives, and the 128GB SSD that the OS is loaded on yesterday and they all came back good.

Booted in to a livecd, formatted the 12gb SSD the OS gets installed to, formatted the drive, installed OMV 5, mounted the arry, created shares, created the user, enabled SMB/CIFS, added the share there. The minute I mapped to the share, the behavior showed up again. I've attached the output of the OMV 5 cat /etc/samba/smb.conf.