late4473

One more follow up - previous solution was not permanent - server continued to die. I'm putting this down to the unRaid FUSE bug (shfs). Resolution which has a 7 day up-time so far...

1) Upgrade to 7.2.0-beta.2 (Can't be any worse that what I've got!)
2) Change all drive references (docker container persistent drives, docker.img, libvirt.img and all VM storage paths) from /mnt/user/... to /mnt/cache/... These are all cache only drives anyway and this takes FUSE out of the equation.

I hope this helps someone!

Will I make 2 weeks of up-time??

To close on this - it WAS to do with an immutable flag...it was just hidden
 
I ended up copying all the data out of my media share and I was left with 2 shares that still had 'operation not permitted' when I tried to destroy them:
 
media/Movie
media/photo-other
 
'media' was an encrypted datashare whereas the nested 'media/photo-other' was not (just saying)
 
I 'unlocked' media via the GUI and this gave a failure message and still showed the open padlock...but magically this enabled me to see the files in photo-other and:

 
So the 'masked' files were immutable preventing actions noted in the OP.  So I cleared the flags, deleted the files, then destroyed the datasets.
 
The take away message: take care with encrypted dataset where you (accidentally or otherwise) create files and folders whilst it is locked!
 
I just glad this wasn't a bug where ZFS had let me down.  I'd written my files whilst the dataset was locked, so after my weekly reboot and the dataset was unlocked (via a script on array startup) all my files appeared to disappear - and because I had made them immutable (ransomware protection) the dataset couldn't be destroyed!  Confusing but explainable.
 
Cheers all.

Actual solution (following mobo install) was to ensure I had the latest firmware installed on my new mobo.  System has been stable since.