Copying folders between datasets

[kkordisch]

We have a dataset called "A" that houses all of our media. That dataset is owned by a group called Admins, of which the assistant is a member. Then, we have a dataset for each editor, owned by the editor, but also owned by the Admins group. The idea is that the assistant will drag a project folder into the Editor’s dataset so that the editor can make appropriate changes. What happens, though, is that the Editor, who owns their own dataset, doesn’t have write permissions on the folder that the assistant has copied into their dataset.

The datasets were setup with windows permissions but we are working on Macs mounting the volumes via SMB. What is the best way to go about copying the folder from dataset "A" to dataset "B" inherits the permissions from "A"??

 

[Basil Hendroff]

Can you provide the Windows ACLs for the SMB shares associated with A and B, as well as the permissions for the ACEs in each list?

 

[kkordisch]

What is the best way to get those? With the "getfacls" and "smbcacls" command?

 

[Basil Hendroff]

Not sure how you would do this on a MAC, but the easiest way for me is through Windows. Starting with the ACLs, please provide a screenshot of the share security for both A and B as in the example below.

 

[TidalWave]

Hi Seymour,

I work with kkordisch. I've attached the screenshots of ACLs. In this instance the share labeled Channels is the A share and the share Dave.Em... name is the B share.

When the editor, Dave opens up his share he can write to the root, but he can not write within the folder that was copied in there for him by another user.

To be clear, we have an assistant editor who has access to the channels share. He will copy the data from the channels share/dataset into the editors share/dataset from a MAC via SMB. The assistant editor has full access to both shares, but the editor only has read access to the folder copied into his share even though he is owner of it. Yet Dave can write to the root of his share, but not the folder within it. It seems that after the copy the permissions from the channels share are retained within the copied folder.

 

[Basil Hendroff]

@TidalWave Thank you for the screenshots. Can you please provide the ACLs for the copied folder as well?

 

[Basil Hendroff]

Can you confirm that Brian is a member of Admins? Looks like you're pre-FreeNAS 11.2. What version of FreeNAS are you working with?

 

[TidalWave]

Here they are side by side. I was able to recreate the problem in the lab. The assistant is on the admins group, while the editor is on the editors group.

 

[Basil Hendroff]

editor kevin.ke... is on the editors group.

...noting that the editors group does not appear in the previous set of screenshots (not that it matters at this stage).

 

[TidalWave]

We are on freenas verson 11.0

The unnamed security feature of the first screen shots is most likely the group. I can send a screenshot of the accounts and users creation GUI list.

It seems that there might be some confusion on the groups in the user accounts as well as the datasets. But I don’t know.

All I know is that they want a separate dataset for each editor and a big tank for everything else.

 

[Basil Hendroff]

True, but that group is admins based on the last two images of the first set of screenshots. At this stage:
1. Please confirm that Brian... is a member of Admins, and
2. Please supply the ACLs for the copied folder in the destination share Dave...

 

[Basil Hendroff]

It seems that there might be some confusion on the groups in the user accounts as well as the datasets. But I don’t know.

All I know is that they want a separate dataset for each editor and a big tank for everything else.

We'll get to this once I've unravelled what's happening at present.

 

[Basil Hendroff]

Reading between the lines, this is what I think you are after:

There is a collective involved in the production of some work. This collective is made up of a group of individuals. One or a few of those individuals are assistants. The rest are editors. The assistants apportion work to editors (Is there a reason the work is pushed to the editors rather than editors pulling the work down?). Anyone who is not in the collective (apart from system administrators) has no(?) visibility of the work.

Tweak this till you're happy it meets the business requirements. Note: The scope describes work being 'checked-out', but doesn't appear to cover 'check-in' of work. Does the scope need to be expanded to cover this as well?

I still need the information requested below to confirm a suspicion I have.

1. Please confirm that Brian... is a member of Admins, and
2. Please supply the ACLs for the copied folder in the destination share Dave...

 

[TidalWave]

Hi Seymour,

We can't get any more screenshots right now, but I have been able to replicate the problem in the lab. And by changing the editors share to editors group, this allows the editor to write to the data which the AE copied into the editors folder.

Now the only problem is that by changing the datasets to editors group, each editor can see each others datasets, which we don't want. So I'm thinking make each editors dataset into his own primary group based on the editors name. Then go into the AE account and add each editors group into the auxiliary group from the AE's account page. This should give the AE permission to write to the editors share.

I think this will work, but it's a bit messy as each editor will have to be added into each assistant editors auxiliary group. It seems like a good solution to me. What do you think?

in regards to your suggestion the AE has to be the one to put the data into the editors workspace because the AE is in control of all the data and they don't want to give the AE permission to the editors workspace, but that may change depending on their needs.

Anyways, I've been reading many times that working on shares or dataset permissions is best used by using windows machine and right clicking and going to security. However, I only see the group and user account, I cannot add more users to the share via a windows client machine.

 

[Basil Hendroff]

each editor can see each others datasets, which we don't want.

... and yet it is acceptable for the AE to see (and write to) every editors' personal share. This, of course, is a consequence of pushing work out to the editors. It would be better, from a privacy perspective, if personal shares are just that... personal... and only visible to the individuals that own the share.

make each editors dataset into his own primary group based on the editors name

Good idea

the AE is in control of all the data and they don't want to give the AE permission to the editors workspace

I agree. The AE's share is a personal share as well and should be kept private.

I think this will work, but it's a bit messy as each editor will have to be added into each assistant editors auxiliary group. It seems like a good solution to me. What do you think?

Have you considered a separate share with the appropriate permissions that is accessible to the collective? This common workspace can act as a distribution point for work. This approach maintains the privacy of assistants and editors personal shares. For example, in its simplest form, this common workspace might have write permission for both assistants and editors. Assistants can still push work into this workspace. Editors check-out work when they pull work down into their personal workspaces and check-in work when they push the drafts/finished product back up to the common workspace. An example of what the dataset permissions might look like...

​

Anyways, I've been reading many times that working on shares or dataset permissions is best used by using windows machine and right clicking and going to security. However, I only see the group and user account, I cannot add more users to the share via a windows client machine.

Correct. Fine tuning of ACLs is done through a Windows account with appropriate permissions. I would encourage you to study the videos mentioned below to see how this is done. This paragraph is an extract from the FreeNAS User Guide.

SMB Tips and Tricks shows helpful hints for configuring and managing SMB networking. The FreeNAS and Samba (CIFS) permissions and Advanced Samba (CIFS) permissions on FreeNAS videos clarify setting up permissions on SMB shares. Another helpful reference is Methods For Fine-Tuning Samba Permissions.

 

[TidalWave]

Thank you so much!

No matter what I do I cannot pull a username from the freenas on my windows client machine. I got to advanced and I want to add a user which I created on the freenas via a windows client on my SMB share. But no matter what username I use to "get access" to the list of names on the freenas, I am denied and I only get a list of basic windows objects to add. It's really frustrating!

I've tried logging in as the editors name, using the editors name as the second set of credentials, but nothing. Then I tried root, then I tried an admin user. Nothing I do will allow me to add a user off the freenas into the windows smb share via a windows client. It always says permissions denied when I try to apply it.

 

[Basil Hendroff]

A sleight of hand is required.

Anyone who is not in the collective (apart from system administrators) has no(?) visibility of the work.

You most likely brushed over the point above, but it's the key to unlocking Windows ACLs. While I've suggested that personal shares should remain personal, there is one group of individuals that require complete control over all objects connected with the FreeNAS server. These are your system administrators. The frustration that you've felt is due to that lack of control. Let's look at an example.

This is a dataset created for a new user connor. Notice the (default) Unix permissions associated with this dataset. Connor has full control over the dataset, and others have read access to the dataset. To make this dataset available to Connor in the Windows world, an SMB share is attached to this dataset. Through this mechanism, personal storage space on the server is made available to Connor. Let's now look at the permissions on the Windows share that maps to this dataset.

What you're seeing is how those Unix permissions get mapped to Windows ACLs. Two issues become blindingly apparent. The first is that Everyone, including non-FreeNAS users, on the network has read access to Connor's personal share. Connor's personal share isn't really personal. The second is the system administrator, who created the dataset and SMB share on the FreeNAS server, is nowhere to be seen. Her powers were relinquished once she left the FreeNAS server. Her control needs to be restored if she is to effectively assist her clients.

To address these two issues, log in as connor (who has full control over his personal share) on a Windows client and tweak the permissions to remove Everyone and include the system administrator making sure to give them full control over the share. Note: When dealing with existing users who will already have stuff in their share, don't forget to allow the permissions to propagate down to all objects within the share.

In this example, the group admins is given administrator rights to the share.

With the Windows ACLs tweaked, the share has become truly personal. Connor may call on the administrator from time to time to help him resolve issues within his personal share, but no one else has any visibility of the share contents.

 

[TidalWave]

Hi Seymour,

Thank you so much for your wisdom, however I'm running into an error. I've attached my screenshots, basically I cannot pull the list of users from the Freenas through my windows client machine no matter what credentials I use. I'm logged in as the editors name, and I've set the permissions up as you suggested, but when I select "locate" to find the username Admin it asks for an extra set of credentials, then says object not found... no matter what credentials I type. I've tried all of them, and even different workgroups. Any suggestions?

 

[Basil Hendroff]

This is a different problem. The hurdle to overcome is to figure out why name lookup between the Windows client and FreeNAS server is not working.

Are you using a directory service (such as Active Directory) or configuring authenticated access with local users? https://www.ixsystems.com/documenta...iguring-authenticated-access-with-local-users I'm going to assume the latter.

Are the client and the FreeNAS server in the same workgroup?

What Windows client are you using? Windows 7 or 10? If the latter, are you logging in using a Microsoft account? It adds a level of complication. It will be easier to troubleshoot if you have access to a Windows 7 client.

I notice you've got mixed case and punctuation in your FreeNAS user and group names. For troubleshooting purposes, simplify by choosing a name using lowercase letters without any punctuation mark. On both the Windows client (preferably Windows 7) and FreeNAS, create a user with this name. Make sure the password matches for both the Windows and FreeNAS user. Log in on the client as this user and then attempt a lookup of the FreeNAS user. What happens?

 

[TidalWave]

Oh my! how utterly helpful! Thank you so much!! :)
I was using Windows server 2016 as my test client... I switched over to windows ten pro and it allowed me to add users. Wow, so much time spent on this. Thank you so much!