*

[TinTIn]

Hi All,

If I create 20 Windows Datasets off my main dataset let's call it 'tank' is there any reason I couldn't just share 'tank' and then use ACLs to control access to each dataset? It would mean that all users would mount 'tank' and then traverse to their access points but this would be easier than sharing 20 datasets but just want to make sure I'm not missing something important.

Many thanks,

Sent from my iPhone using Tapatalk

 

[DifferentStrokes]

Well TinTin, I'd say that depends. Do all the users need access to all the shares. You maybe able to do what you need with permissions. Can you give us a little more information on what exactly you are trying to do?

 

[TinTIn]

So no the users won't need access to all the shares. I'll create a stub dataset off tank and then three stubs off that representing the three different groups that require access. After that each group will have a serials of sub datasets some viewable by all members of that specific group but others only visible to senior members. Hope that makes sense. The reason I'm asking is that I'll be using ZFS replication to backup one box to another in a different location and in the event of my server or pool collapsing I'd like to send the users to the other box to access their shares. If only the parent dataset is shared it would be an easy transition however if I had 20 shares then I'd have to set them up on the other box. Hope that makes sense too.


Sent from my iPhone using Tapatalk

 

[DifferentStrokes]

While I don't know everything I do believe that this is something you could do with permissions and a single share. In less maybe you need multiple datasets to snapshot separately.

 

[TinTIn]

I like the idea of being able to set different quotas on the various datasets and even compression.


Sent from my iPhone using Tapatalk

 

[Ericloewe]

I'd definitely avoid doing this with the top-level dataset, but it can work with a sub-dataset with several children.

 

[TinTIn]

Thanks Eric, so perhaps not share tank just one below?


Sent from my iPhone using Tapatalk

 

[cyberjock]

Yet another TinTin thread. Didn't take my advice before eh? ;)

 

[DataKeeper]

Run Tintin, Run! Lol :D


Sorry, couldn't be helped!

 

[TinTIn]

I love you guys


Sent from my iPhone using Tapatalk

 

[anodos]

Just a couple of quick points off the top of my head. When you are determining how many shares to create, you should evaluate your situation in terms of (1) access control and (2) data flow.

Access Control. Speaking from personal experience, your plan swill generate a massive administrative headache. As much as possible you want to define your access controls at a share level. This allows you to make some shares hidden by appending a $ to the shares name "IT$", simplifies the recovery process if something goes horrifically wrong with your permissions, keeps things easily auditable and comprehensible, and doesn't rely on convoluted acls. Most importantly, it allows access to be easily controlled through group policy by automatically mapping required shares depending on organisational unit (please don't tell me we're talking about a standalone server).

What you are thinking of doing will probably end up descending quickly into an incomprehensible permissions ratnest. It might work for a home user, but it will probably backfire badly as you scale up.

Data flow. If end user workflow involves lots of moving files from folder'A' to folder 'B', then you should do whatever you can to have 'A' and 'B' in same dataset and share so that samba will use server-side copy.

Addendum. In a windows network with more than 10 workstations, network drives should never be manually mapped. This should be controlled by group policy. This actually simplifies failover to backup server. For example, you have your mega primary server 'A' that in normal situations hosts your shared content. Server B is your replication target. You have two sets of group policies controlling mapped network drives (normal situation - enabled, and it hits the fan - disabled). If A goes down, disable and enable respective GPO and push GPO refresh. Done. Works if you split data between multiple replication targets.

 

[TinTIn]

Good points andos.

1. This is a standalone server but it's only offering data to 30 people tops.
2. Interesting point about data flow I hadn't considered.
3. The storage will be accessed by Windows, Mac and Linux clients so group policy is out the window.

Thanks for your thoughts.


Sent from my iPhone using Tapatalk

 

[anodos]

Good points andos.

1. This is a standalone server but it's only offering data to 30 people tops.
2. Interesting point about data flow I hadn't considered.
3. The storage will be accessed by Windows, Mac and Linux clients so group policy is out the window.

Thanks for your thoughts.


Sent from my iPhone using Tapatalk

There are tools to extend group policy/ SSO to Mac and linux clients. Anyway, sounds like you have your hands full.

Remember: under promise, over deliver. (The first part of that is often the hardest) :)

 

[TinTIn]

When you say "As much as possible you want to define your access controls at share level" do you mean using owner and group instead of ACLs? Or do you mean create share points for each ACL set?


Sent from my iPhone using Tapatalk

 

[anodos]

When you say "As much as possible you want to define your access controls at share level" do you mean using owner and group instead of ACLs? Or do you mean create share points for each ACL set?


Sent from my iPhone using Tapatalk

Use ACLs. There is no one-size-fits-all for designing your samba shares, but 'one big share' is usually not the correct answer. No offense, but doing 'one big share' is often a quick and dirty way of getting around IT not understanding their employers workflow.


An unrelated example of how this can be a bad idea:

A while ago I met someone who had the following sharing setup:
\\server\share
A department head was granted write access to \\server\share
and was mapped to the following:
Q: - \\server\share
R: - \\server\share\foo
S: - \\server\share\bar

The department head decided that she could delete the "foo" folder on drive Q: since all the data was already in drive R:.