Dataset missing folders and files

Well I jacked one of my datasets. I was attempting to provide access to a new user and it didn’t go well. I stripped the ACL and started over adding in myself and the existing users. That is when I lost access to files and directories within that dataset. I’ve since learned that one must restart the Samba service after making changes.

I’m looking for help on how to gain access to those directories and files. Here is some info:

Truenas Scale 24.04
Dataset: /tank2/
Within the tank2 dataset I have two datasets (/tank2/Main and /tank2/Media)
Missing folders: /tank2/Media/Share Movies/, /tank2/Media/Shared Music/, /tank2/Media/Shared TV Shows/, /tank2/Media/Shared Pictures/ and after the issue, I now have /tank2/Media/jim and /tank2/Media/debb/ showing up as new datasets.

Logging into the shell I can still see the directories under:/mnt/tank2/Media/
and all of the files are still there.

When this all happened, I noticed two addition datasets showed up under that dataset in question, that were named previous users (/tank2/Media/jim ( I suspect it was .trash directories and the like??

Several months ago, I did replicate the tank2 complete dataset to a usb drive. Because the tank2 dataset includes another dataset called /tank2/Main and it is working fine, I didn’t wan to try to copy or restore the whole tank2 dataset.

I also have a snapshot from three months ago. I attempted to rolled it back but nothing changed. I was able to re-establish access to the SMB share on a linux PC. However the files are directories are not showing up. I created a new folder using my linux desktop called test (/tank2/Media/test/ and I can read/write to it fine.

So, I’m not sure how to proceed without creating more issues. Any advice would be appreciated. I’ve read through the Documents Hub website on Managing Datasets but it just created more confusion for me.

Thanks for any help/guidance!

It’s hard to tell what’s going on (and what you intended).

For starters, what is the true dataset structure on your pool?

zfs list -t filesystem -r -o space tank2

What does the pool’s history reveal about creation and destruction of datasets?

 zpool history tank2 | grep "create\|destroy" | grep -v @

It’s recommended to post large text outputs within “details” and “codeblocks” like this:

[details=Name of text]
```
PASTE
YOUR
OUTPUT
IN
HERE
```
[/details]

It will look like this when you submit your post:

Name of text
PASTE
YOUR
OUTPUT
IN
HERE

Understood, and thank you for taking the time to help me!

My intent was to simply provide a new user access to /tank2/Media/. However, when I modified the ACL to include the new user, that user still didn’t have access via SMB shares. Additional reading has lead me to believe that maybe I needed to restart the smb service?? After attempting to make additional changes including stripping the ACL, I lost access to those directories.

I’m really confused how the datasets and shares work together. I believe that ACLs are only applied to datasets correct? If I intend to share these datasets via smb, does the dataset ACL type need to be SMB/NFSV4? Currently, the Media dataset " ACL type"is set to Inherit. However, under the permissions settings under GUI, it shows “NFSv4” permissions. Is this because it’s being inherited from the “tank2” dataset? Or are we talking about apples and oranges?

dataset structure
root@truenas[~]# zfs list -t filesystem -r -o space tank2
NAME              AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
tank2             3.56T  1.69T      156K    185K             0B      1.69T
tank2/Main        3.56T  1022G      306G    716G             0B         0B
tank2/Media       3.56T   707G     14.2K    707G             0B       355K
tank2/Media/debb  3.56T   170K        0B    170K             0B         0B
tank2/Media/jim   3.56T   185K        0B    185K             0B         0B
tank2/Restore     3.56T   170K        0B    170K             0B         0B
pool history
root@truenas[~]# zpool history tank2 | grep "create\|destroy" | grep -v @
2023-12-28.10:36:04  zfs create -o aclmode=restricted -o casesensitivity=insensitive -o org.freenas:description=Media Access -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/public
2023-12-28.14:02:34 zfs destroy -r tank2/public
2023-12-28.14:09:28  zfs create -o aclmode=restricted -o casesensitivity=insensitive -o org.freenas:description=Media Share -o copies=1 -o org.truenas:managedby=192.168.1.50 -o xattr=sa tank2/public
2023-12-28.17:22:10 zfs destroy -r tank2/public
2023-12-28.19:47:23  zfs create -o aclmode=restricted -o casesensitivity=insensitive -o copies=1 -o org.truenas:managedby=192.168.1.51 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/public
2023-12-30.13:14:42 zfs destroy -r tank2/public
2023-12-30.13:35:57  zfs create -o aclmode=passthrough -o casesensitivity=sensitive -o org.freenas:description=testing -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/New
2023-12-30.13:39:13  zfs create -o aclmode=passthrough -o casesensitivity=sensitive -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/New/Share1
2023-12-30.13:39:37  zfs create -o aclmode=passthrough -o casesensitivity=sensitive -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/New/Share2
2023-12-31.13:53:50 zfs destroy -r tank2/New
2023-12-31.13:57:04  zfs create -o aclmode=restricted -o casesensitivity=insensitive -o org.freenas:description=Personal files and folders -o copies=1 -o org.truenas:managedby=192.168.1.50 -o xattr=sa tank2/Main
2023-12-31.13:57:56  zfs create -o aclmode=restricted -o casesensitivity=insensitive -o org.freenas:description=For access to Media -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/Media
2024-01-01.15:54:03  zfs create -o aclmode=passthrough -o casesensitivity=sensitive -o copies=1 -o org.truenas:managedby=192.168.1.50 -o quota=none -o refquota=none -o refreservation=none -o reservation=none -o xattr=sa -o special_small_blocks0 tank2/rsync_test
2024-06-27.15:29:20 py-libzfs: zfs create -o aclinherit=passthrough -o aclmode=restricted -o acltype=nfsv4 -o casesensitivity=insensitive -o org.truenas:managedby=192.168.1.50 -o xattr=sa tank2/Main/Restore
2024-06-27.16:29:48 zfs destroy -r tank2/Main/Restore
2024-06-27.17:12:28 py-libzfs: zfs create -o aclinherit=passthrough -o aclmode=restricted -o acltype=nfsv4 -o casesensitivity=insensitive -o org.freenas:description= -o copies=1 -o org.truenas:managedby=192.168.1.50 -o xattr=sa tank2/Restore
2024-07-24.07:37:58 zfs destroy -r tank2/rsync_test
mount details
root@truenas[/mnt/tank2/Media]# ls -lh
total 186K
drwxrwx--- 236 jim Home 236 Feb  5  2024 'Shared Movies'
drwxrwx--- 349 jim Home 349 Apr 29 07:57 'Shared Music'
drwxrwx---   2 jim Home   2 May 29 18:46 'Shared Pictures'
drwxrwx---  14 jim Home  14 Mar 16  2024 'Shared TV Shows'

Update:

I fixed my issue. Here are the steps I took:

I first tried a reboot and several attempts to strip the file system ACL and reset share permissions to no avail.

I found it odd that I had access to the share and could write data to it but the directories and files did not show up in the file structure /mnt/tank2/Media/

I finally decided to just delete the share /tank2/Media then rebooted the server. I then recreated the share and the directories and files returned. I added in the user permissions and all seems to be working fine.

One thing I learned was to make sure anytime users are added or changed to restart the SMB service. Maybe this cause some data corruption? Not sure.

Apologies for the late reply. For some reason I was never notified that you replied yesterday. It doesn’t even show in my notification history…

Adding users shouldn’t require restarting the SMB server.

Changing user group membership will require a new SMB session for already-logged-in users since the user token that defines group memberships is generated when connecting to the share. A shortcut to achieving this goal is to restart the SMB server, but it’s generally less painful to just remount the share on the client.

It’s hard to say what the original problem was without detailed configuration details of the SMB share.

Not a problem, thanks for responding!

Thank you for your comments. Duly noted!