Seeking some assistance with this as I’m at wits end trying to figure it out. I recently moved and due to an error on my part my pool got corrupted and I had to recreate it from scratch and recover my data from my secondary system. I was able to salvage my TrueNAS install so nothing changed there but ever since recovering my data I can no longer delete files on my SMB shared datasets like I used to. All the directories/files are set to be apps:apps with 777/666 for directories and files respectively. I’ve checked the read-only option that gets set sometimes when recovering a ZFS dataset and it’s off. I’m NOT using any ACLs and didn’t have any set before either. I can create new directories and delete them without issue but when I try and delete something that is already there I get an error in Windows saying I need the file owners permission despite the wide open settings mentioned above. Thoughts?
It needs to delete the files first, and so you need delete permissions on those too.
Also, SAMBA will do stuff based on the Unix userid mapped to your windows userid and not the apps uid/gid, so you need your Unix userid/group to have appropriate permissions too.
Appreciate the quick reply.
If the file permissions are 777/666 that means owner has full, group has full and other has full. I believe that means my Windows id (spunky) that is mapped to the same Unix id (spunky) on the box falls into the “other” section for UNIX permissions and has full ability to do whatever on the directory/file.
This has always worked before without issue until the restore.
At the UNIX level I’m able to remove the file without issue as my Unix ID (spunky) with the files owned by apps:apps.
You need to work your way up the dataset hierarchy until you find one which is not inherited.
Also, don’t forget that in TrueNAS there are ACLs in addition to normal Unix user/group/other permissions.
The dataset in question is the top level. Next level up is my main pool. This dataset is data01/download so I believe it needs to not inherit here. I seem to recall this from before I had to recover…
As I mentioned I don’t have any ACLs applied unless TrueNAS is hiding them. There are no plus signs on the permissions indicating an ACL is applied to the directories/files.
@Protopia hit the mark. It was the ACL settings on my dataset inheriting from the pool. I set them as noted below and now all is working as it was before. My guess is that since I had to recreate the pool and then the dataset to restore the data as I mentioned I missed setting this as I had done before.
Kudos and much appreciate your patience and assistance!
Is your pool mounted as Read/write, or just read only?
@Gyula_Masa it’s mounted read/write.