Hello, I just completed migration of my data from my synology 1817+ to a new ugreen dxp-8800 (TrueNAS Scale), and I’m sure there is a better way to have moved 42TB’s I ended up simply creating a new volume on the 8800 and installing the syncthing app on both devices and syncing the SMB shares from the 1817+ to the 8800.
once the shares were synced over, I created a dataset called volume1 and then smb shares to each individual path migrated over, I’m a total novice to truenas and now am completely out of my element as I now realize that I have not spent enough time learning how to properly create datasets and the smb shares underneath. So this is what my volume looks like, it’s pretty basic in that it has an implied root and subfolder structure
My problem is that the both filesystem & share acls are a complete mess as I have butchered them to death trying to get them to mimic how I had them on the synology. I have since learned and continue learning how to make them better, however my million dollar question is, can I remove the share and parent dataset and recreate them without blowing away the underlying data residing in the /mnt/volume1 folder? if not then I’m left with moving the data to another device and recreate the dataset as it should be set up? If you made it this far, thank you very much for your time
You can safely delete shares. This won’t destroy any data (apart from the share config). Shares are just some lines in smb.conf.
You can not delete a dataset without destroying its underlying data. Well, you can clone datasetA to datasetB and then promote datasetB, but that is another topic.
It seems that you are using terminology wrong. Perhaps this is one of the reasons there are still no replies. Did you name your pool “volume1”? When you speak about “moving the data to another device”, what do you mean by “device”?
What exactly do you want to accomplish by deleting some of your datasets? Do you want to just rename them? Or change other params (if so – which)?
Thanks for replying, that is correct, I have created two pools volume0 (currently unused) and volume1 and that helps a lot that I can remove and recreate the SMB shares however if I understand you correctly, I cannot remove and recreate the datasets for these volumes. So, with that being said, is there a way to recreated the acl’s for the dataset? mine do not seem to align with what I am reading online for how I believe these need to be setup so I am trying to figure out a way to get to a clean starting point and about the comment about moving the data to another device, I was talking about the possibility of moving the data off of the new ugreen device to another storage device if that is what it took to remove and recreate the volume1 dataset as kinda a option of last resort however really hoping to be able to somehow start over with the dataset ?
I use only simple scenarios for ACL – like only 1 user can RW on the dataset, or only 1 group can RW, or everyone can RW etc. So I won’t be able to help you.
Regarding moving data to another storage device, usually there is no need for this, as you can just move the data from one dataset to another (and that would be much faster).
But it looks like you want to change the root dataset settings… I don’t know whether it is possible or not – afaik some settings can be changed only during creation.
I think you should be more specific about your issue.
Something like “I have this type of ACL for my root dataset, and I’ve read that it is bad because of <…>. How do I change ACL of my root dataset without destroying the underlying data?”.
Then perhaps some seasoned truenas users could help you.
When you created the datasets volume1/folder1, volume1/folder2, etc. did you apply the SMB Dataset Preset?
You can always reset the permissions / ACLs of a dataset and recursively apply them to the entire dataset. You do not need to destroy and re-create the dataset to accomplish this.
When you change the ACL, in some cases you are replacing the old ACL.
In the worst case you may have to Strip ACL (recursively) and then create and apply new ACLs. This assume you do not have very complex ACLs that vary as you drill into the data. Re-creating those will be a nightmare.
From the context it did not seem the OP had complex ACLs that varies within the shares.
Yes, this is all I’m trying to accomplish is just very simple group RW permissions and possibly a user, that all. however looking at the volume1 dataset it looks like this, and I believe this happen when I installed and used syncthing?
**Roles:**
Apps: This dataset is used by: syncthing
SMB Shares Attached: Dataset is shared via SMB as 'backups', 'containers', 'archive', 'media', and 'downloads'
**Permissions**
Owner: apps
Group: apps
**Unix Permissions**
person: apps Read | Write | Execute
people: apps Read | Write | Execute
groups: Other Read | Execute
So, I think that the apps owning this dataset is possibly impacting the permissions to my smb shares attached to it, the only way so far I have been able to use the smb shares is assigning @ everyone FULL | ALLOWED which is not how I want this and Im ok with recreating the smb shares, now just trying to understand how to level set the dataset for volume1
yes I believe that I did originally select SMB Dataset preset
Despite how poorly I have explained all this, in the end I’m just trying to set up a plain and simple permissions scheme, by just assignign a single group to each of the different shares. I bought this behemoth as expansion and future container projects however the only app currently on is is the syncthing app, and I didn’t mean for it to own the device as it appears to be
You can easily change the owner and/or the group of the dataset in the Details for <dataset-name> -> Permissions -> Edit.
Just do not forget to tick the “Apply user” and “Apply group” checkboxes.
From the Permissions menu (navigate to Datasets → select the dataset you want to modify) in the right side navigation. But if you are still running SyncThing then it will (probably) overwrite any changes you make. Start by disabling SyncThing (assuming you have completed the data migration) and then make changes to the Permissions. Also note that SMB makes use of ACLs so you want them enabled. Once you get your initial permissions set you should be able to manage permissions from the Windows side via your SMB connection (assuming the user you make the SMB connection as has the rights to).
And as @swc-phil mentions, remember to check the “apply” buttons for basic user and group changes.
