Dataset Share Type purpose?

[RedBear]

Share Types for datasets. Why choose one over the others?

Before I wrote this up I did a search to see if this question has been answered adequately before. As far as I can tell, it really hasn't. The only information I encountered was a couple of brief comments by a user called SweetAndLow to the effect that A) ZFS datasets can sort of be thought of like filesystems, or maybe partitions, on non-ZFS systems, and B) that "Share Type" simply determines what sort of permission structure the dataset uses natively, such as POSIX permissions versus Windows-style ACLs. While this answer may be technically correct and somewhat enlightening, I don't believe it even begins to answer the question people really want answered when they ask "What is this 'Share Type' thing in the Edit Options dialog for my dataset, and why is it separate from all the actual AFS/CIFS/NFS/WebDAV/iSCSI 'Sharing' stuff?"

No, the real question that needs answering is, of course, "How does my choice of Share Type for a dataset _interact_ with my choice(s) of protocol(s) to use to share that dataset?"

It must be noted that from my perspective (and, I think, many typical computer users) FreeNAS and FreeNAS users seem to come at this sharing thing kind of ass-backwards. I've seen it recommended multiple times to "create one dataset per share", and witnessed the "wizard" create a dataset automatically with the same name as I specified for the share, obviously intended only to be used with that sharing protocol. Nothing about this makes sense to me at the moment. From sharing between Macs and PCs starting with Win98 and OS 9, to working with consumer NAS devices for years, to setting up an OpenBSD server many years ago sharing some common office files via both Netatalk and Samba, I have always understood that it is the job of the software doing the actual sharing to translate transparently between the permission structures of the sharing protocol and the sharing clients, and the permission structures of the underlying filesystems being shared. Whether the underlying filesystem is UFS, Ext3, NTFS, FAT32, HFS+, BeFS, ZFS or what-have-you.

Typically, when setting up a folder to be shared from OS X or a consumer NAS, you simply choose the folder to share and then check some boxes for which protocols you wish to use to share the folder. Or, frequently, the protocols simply apply to everything on that machine that is chosen for sharing, and aren't even tied to specific folders at all. By default on OS X shared folders are shared via both AFP and SMB, unless one protocol is turned off by the user.

From this perspective it is quite confusing to be asking the user setting up a FreeNAS server whether a dataset (or what a typical new user will see as a "folder to be shared") is a UNIX, Windows, or Mac "Share Type". What share type should be chosen for WebDAV sharing, or iSCSI? What if I want to use both AFP and CIFS to share the same dataset on a mixed Mac/PC network? This is quite common, in my experience, in small offices. There is certainly zero information in the GUI that would help the typical user to understand which choice to make under any given circumstance. The user guide currently has this to say on the matter:

"Share Type - drop-down menu - select the type of share that will be used on the dataset; choices are UNIX for an NFS share, Windows for a CIFS share, or Mac for an AFP share"

Quite unhelpful if one is used to sharing the same data via multiple protocols. What is the benefit to creating a single dataset per share? Is there some kind of negative interaction or bug that will be encountered by sharing clients if multiple protocols are used to share the same dataset? What if the "wrong" share type is chosen, or the "wrong" sharing protocol is used? What difference does it make? What problems might be encountered? Why is it recommended to have one dataset per share? Is there another solution to sharing the same common set of files to users of different platforms? Just stick with CIFS and make the best of it?

I'm hoping this issue can be thoroughly fleshed out within just a few posts from knowledgeable FreeNAS admins, and this thread can become a solid resource for all new FreeNAS users that come here looking for an explanation of the importance of this dataset option and how to make the right choices for their individual use cases. Perhaps it could even be stickied at some point, or the information added to a new-user guide, if we come up with some good answers.

I appreciate any input anyone has on this issue.

 

[Ericloewe]

The dataset options set the permissions type. This is best defined initially and not changed, otherwise the results won't be pretty.

"How does my choice of Share Type for a dataset _interact_ with my choice(s) of protocol(s) to use to share that dataset?"

See above.

It must be noted that from my perspective (and, I think, many typical computer users) FreeNAS and FreeNAS users seem to come at this sharing thing kind of ass-backwards. I've seen it recommended multiple times to "create one dataset per share", and witnessed the "wizard" create a dataset automatically with the same name as I specified for the share, obviously intended only to be used with that sharing protocol. Nothing about this makes sense to me at the moment. From sharing between Macs and PCs starting with Win98 and OS 9, to working with consumer NAS devices for years, to setting up an OpenBSD server many years ago sharing some common office files via both Netatalk and Samba, I have always understood that it is the job of the software doing the actual sharing to translate transparently between the permission structures of the sharing protocol and the sharing clients, and the permission structures of the underlying filesystems being shared. Whether the underlying filesystem is UFS, Ext3, NTFS, FAT32, HFS+, BeFS, ZFS or what-have-you.

Think of the dataset as a superfolder that is effectively a separate filesystem. That means you can easily set some wide-ranging options (like permissions type).

iSCSI

iSCSI is a raw format. Permissions don't really apply in the traditional sense.

WebDAV sharing

Good question. Unix, I'd expect.

What if I want to use both AFP and CIFS to share the same dataset on a mixed Mac/PC network?

That's a genuine Very Bad Idea (tm). Think file corruption and the like. AFP is dying, anyway. Use CIFS with Windows in the mix. Apple is moving towards SMB.

 

[RedBear]

The dataset options set the permissions type. This is best defined initially and not changed, otherwise the results won't be pretty.


See above.


Think of the dataset as a superfolder that is effectively a separate filesystem. That means you can easily set some wide-ranging options (like permissions type).


iSCSI is a raw format. Permissions don't really apply in the traditional sense.


Good question. Unix, I'd expect.


That's a genuine Very Bad Idea (tm). Think file corruption and the like. AFP is dying, anyway. Use CIFS with Windows in the mix. Apple is moving towards SMB.

Please don't take this the wrong way, but your answers here are far too terse and without a lot more information just boil down to the same vague "this is what is recommended" without any further explanation why, which is exactly what I was trying to avoid.

I'm not going to assert that anything you've said is incorrect, and I'm too tired to write the encyclopedia of questions I want to write in response to this right now. But I will point out again that OS X, OS X Server and various NAS devices I have worked with for the last decade or more have been happily sharing the same files via both SMB and AFP simultaneously, by default even, and there is no epidemic that I know of of file corruption among shared files on these platforms. So without much more in-depth information it is difficult to understand why this is considered such a big deal on FreeNAS. Note that I am not disagreeing, just seeking better understanding. For myself and every FreeNAS user that comes after me.

I remember some issues from 16 or so years back when I was putting together that OpenBSD file server, about SMB and AFP using different file locking mechanisms that could cause some issues when an AFP and a SMB user tried to work with the same file, but that had very little to do with permissions. Does that have something to do with why it's a Very Bad Idea?

Also, if the Share Type should not be changed after the dataset is created, why is it a drop-down menu in the dataset Edit Options dialog that can be easily changed at any time? Why won't the results be pretty? How the hell is the typical FreeNAS user supposed to know not to change something that seems designed to be easily changed? Nothing I've seen in the FreeNAS GUI or the guide seems to indicate to the user that changing the Share Type will cause problems. What if the dataset is empty when you change it?

I'll agree that support for SMB is vastly better on OS X these days than it was back in the OS 9 days when I really needed to use AFP (for reasons I can't clearly recall now), but AFP is still necessary for Time Machine compatibility (although that should definitely be in its own dataset shared only via AFP). I don't think it can be declared dead just yet.

 

[SweetAndLow]

So you are asking some pretty big questions. These types of questions aren't easy to put into text for and most people who know the answer either wrote the code or have played around with it enough to understand what things do and how they work.

I think there are a couple parts to the share/dataset/protocol discussion. Once you have a good understanding of these things individually then you can start to mix and match them to get the solution that works for you.
1. What are the protocols and what they do.
2. What is a dataset and what makes it special or different from a random folder.
3. What types of permissions can you have and what are their difference.

You asked about using two protocols to access the same share and why people say not to do this on freenas but it seems to be ok on other platforms. It is possible to setup multiple protocols to access the same dataset or files and you can choose either share type, it will work, but it will not work in certain cases. These cases are when you access the same file at the same time from two different protocols. Each protocol has it's own locking semantics and those semantics are not shared amongst the protocols(I know of one enterprise system that does this). So in the event that you open a file that someone else has open when they write to it you don't get the updates and when you write you will overwrite all the modifications that the previous write operation did. This behavior is exactly the same on the other platforms that allow you to share the same data over multiple protocols. It's just that those features are not used as core infrastructure for a business. So most of the time the users of that feature on those other platforms don't care and probably have no clue. When you are on the freenas forums things are more focused on reliability and doing it correctly so when people start sharing using multiple protocols someone on here brings it up.

Now the other question that you asked about does share type really matter. I'm willing to be corrected on this if someone can provide technical evidence but I don't think share type matters for technical reasons. I do thing it matters from a users perspective. Technically the permissions get mapped into the same thing under the covers wether you are using ACL's or mode bits. But the interface the users see's is much different. If someone on widows looks at permission that are exposed as posix then they see special permissions set and all the other boxes greyed out. This isn't the best experience and can be confusing because if they change them to not use the special bits and to use the normal windows stuff they will get unexpected results. The same goes for using ACL's, if you modify a file permissions that has ACL's enabled using chmod then you don't actually get the permission you think you set. This is because 755 actually means something different when using ACL's and that behavior is hidden from the user and can only be figured out by playing with it and learning, most people don't actually care to learn ;). And one last thing you can switch between share types all you want you just need to make sure to remove all the previous permissions set and I agree that this feature in the webUI is strange and doesn't always work easily.

I hope this answers some questions or raises more!

 

[anodos]

Please don't take this the wrong way, but your answers here are far too terse and without a lot more information just boil down to the same vague "this is what is recommended" without any further explanation why, which is exactly what I was trying to avoid.

I'm not going to assert that anything you've said is incorrect, and I'm too tired to write the encyclopedia of questions I want to write in response to this right now. But I will point out again that OS X, OS X Server and various NAS devices I have worked with for the last decade or more have been happily sharing the same files via both SMB and AFP simultaneously, by default even, and there is no epidemic that I know of of file corruption among shared files on these platforms. So without much more in-depth information it is difficult to understand why this is considered such a big deal on FreeNAS. Note that I am not disagreeing, just seeking better understanding. For myself and every FreeNAS user that comes after me.

I remember some issues from 16 or so years back when I was putting together that OpenBSD file server, about SMB and AFP using different file locking mechanisms that could cause some issues when an AFP and a SMB user tried to work with the same file, but that had very little to do with permissions. Does that have something to do with why it's a Very Bad Idea?

Also, if the Share Type should not be changed after the dataset is created, why is it a drop-down menu in the dataset Edit Options dialog that can be easily changed at any time? Why won't the results be pretty? How the hell is the typical FreeNAS user supposed to know not to change something that seems designed to be easily changed? Nothing I've seen in the FreeNAS GUI or the guide seems to indicate to the user that changing the Share Type will cause problems. What if the dataset is empty when you change it?

I'll agree that support for SMB is vastly better on OS X these days than it was back in the OS 9 days when I really needed to use AFP (for reasons I can't clearly recall now), but AFP is still necessary for Time Machine compatibility (although that should definitely be in its own dataset shared only via AFP). I don't think it can be declared dead just yet.

Windows datasets have the 'aclmode' zfs property set to 'restricted'. This prevents chmod operations. Samba on Freenas uses a module called 'zfsacl', which makes samba use setfacl instead chmod.

 

[RedBear]

Ah, now we're getting something more meaty to chew on.

So you are asking some pretty big questions. These types of questions aren't easy to put into text for and most people who know the answer either wrote the code or have played around with it enough to understand what things do and how they work.

I think there are a couple parts to the share/dataset/protocol discussion. Once you have a good understanding of these things individually then you can start to mix and match them to get the solution that works for you.
1. What are the protocols and what they do.
2. What is a dataset and what makes it special or different from a random folder.
3. What types of permissions can you have and what are their difference.

You asked about using two protocols to access the same share and why people say not to do this on freenas but it seems to be ok on other platforms. It is possible to setup multiple protocols to access the same dataset or files and you can choose either share type, it will work, but it will not work in certain cases. These cases are when you access the same file at the same time from two different protocols. Each protocol has it's own locking semantics and those semantics are not shared amongst the protocols(I know of one enterprise system that does this). So in the event that you open a file that someone else has open when they write to it you don't get the updates and when you write you will overwrite all the modifications that the previous write operation did. This behavior is exactly the same on the other platforms that allow you to share the same data over multiple protocols. It's just that those features are not used as core infrastructure for a business. So most of the time the users of that feature on those other platforms don't care and probably have no clue. When you are on the freenas forums things are more focused on reliability and doing it correctly so when people start sharing using multiple protocols someone on here brings it up.

Aha, so it does have at least something to do with the file locking incompatibilities I read about around the turn of the millennium. Fortunately the file server I was setting up was for a network with maxusers=3, so I didn't worry about it too much at the time. The practical probability of two people trying to edit the same file at the same time was nil, and we had backups. Of course on a network with more users it would be an unacceptable risk.

Hard to believe that hasn't been worked out since then. Even harder to believe that OS X Server is still vulnerable to such a heinous data corruption issue if both AFP and SMB are active on a shared folder. Hard, but not impossible.

Now the other question that you asked about does share type really matter. I'm willing to be corrected on this if someone can provide technical evidence but I don't think share type matters for technical reasons. I do thing it matters from a users perspective. Technically the permissions get mapped into the same thing under the covers wether you are using ACL's or mode bits. But the interface the users see's is much different. If someone on widows looks at permission that are exposed as posix then they see special permissions set and all the other boxes greyed out. This isn't the best experience and can be confusing because if they change them to not use the special bits and to use the normal windows stuff they will get unexpected results. The same goes for using ACL's, if you modify a file permissions that has ACL's enabled using chmod then you don't actually get the permission you think you set. This is because 755 actually means something different when using ACL's and that behavior is hidden from the user and can only be figured out by playing with it and learning, most people don't actually care to learn ;).

So in essence if the "wrong" choice is made for the underlying filesystem's (dataset's) permissions type, the sharing daemon might fail to correctly translate permissions modifications done by clients, and they end up seeing odd behavior from files?

I think a lot of users do try to learn stuff like this but there is such a lack of easy to understand explanations that the technical world often seems totally impenetrable. Only through the patience of current experts is knowledge passed on.

And one last thing you can switch between share types all you want you just need to make sure to remove all the previous permissions set and I agree that this feature in the webUI is strange and doesn't always work easily.

This brings up the question of whether there is a simple and reliable way to remove those permission remnants. If so, shouldn't this be part of what happens when the user changes the Share Type setting? If it has to be done manually then I would have to agree that changing a dataset's Share Type would generally be inadvisable, and complementary-wise the Share Type options should be moved to Advanced Mode. So as not to tempt and/or confuse uninformed users like me.

I hope this answers some questions or raises more!

It does both, thanks!

 

[SweetAndLow]

So in essence if the "wrong" choice is made for the underlying filesystem's (dataset's) permissions type, the sharing daemon might fail to correctly translate permissions modifications done by clients, and they end up seeing odd behavior from files?

Ehh I wouldn't go as far to say the sharing daemon fails to correctly translate them. It's just that they should be managed in the correct way and when mixing protocols and permission types that management becomes more unintuitive. I use posix permissions and do all my sharing via smb and everything works the way I expect it to. But with this workflow you can't easily modify permissions from the windows gui but you can easily modify them from a linux client using smb. The same goes if you look at it the other way, if using acl's you can easily modify things from the windows gui but modifying them from a different platform changes away from the chmod that everyone is use to.

 

[jab416171]

OK, I've got a couple of questions now. I realize this thread is 4 months old, but I have a different use case than what's been discussed here.

I have one windows machine and several flavors of linux in my house. I typically either watch my media on my windows PC, or my Myth frontend running Ubuntu that's plugged in to my TV. I will not modify or write to the media folder from Windows. Is there any harm or risk in doing the following? It sounds like most, if not all, of the problems arise from concurrent modification between different share types, but if one's read only, then that can't happen.

1. Create a dataset with the share type set to UNIX
2. In the permissions, give Group access to read and execute
3. Share the dataset via NFS
4. Share the dataset via CIFS
5. Log in via windows with a user in that group, but not as the owner

In case anyone's curious, I did set this up and get it working. Here's what I did:

1. Create a unix dataset, set the permissions to 755
2. Set the owner to a user I created
3. Create an NFS share, and set mapall user to my user, and mapall group to nobody
4. Create a CIFS share, and mark it read only

Now I can add/delete/manage the fileshare from linux, and watch the media from windows without worrying about anything funky going on.

 

[bbox]

You asked about using two protocols to access the same share and why people say not to do this on freenas but it seems to be ok on other platforms. It is possible to setup multiple protocols to access the same dataset or files and you can choose either share type, it will work, but it will not work in certain cases. These cases are when you access the same file at the same time from two different protocols. Each protocol has it's own locking semantics and those semantics are not shared amongst the protocols(I know of one enterprise system that does this). So in the event that you open a file that someone else has open when they write to it you don't get the updates and when you write you will overwrite all the modifications that the previous write operation did. This behavior is exactly the same on the other platforms that allow you to share the same data over multiple protocols. It's just that those features are not used as core infrastructure for a business. So most of the time the users of that feature on those other platforms don't care and probably have no clue. When you are on the freenas forums things are more focused on reliability and doing it correctly so when people start sharing using multiple protocols someone on here brings it up.

What if one uses separate share protocols of the same kind on a single file/dataset? I. e. two OS X users have their own AFP on same dataset for Time Machine backup?

 

[anodos]

What if one uses separate share protocols of the same kind on a single file/dataset? I. e. two OS X users have their own AFP on same dataset for Time Machine backup?

You'd be much better off creating a separate dataset for time machine backups and apply a quota to it. Time machine wants to fill up all available space.

 

[SweetAndLow]

Afp is dead probably best to just not use it.

I'm not sure I understand your question. You are asking if something should work the way it is suppose to work. If you are trying to share a time machine backup that is going to depend on your application not your protocol or filesystem.

 

[bbox]

Afp is dead probably best to just not use it.

I'm not sure I understand your question. You are asking if something should work the way it is suppose to work. If you are trying to share a time machine backup that is going to depend on your application not your protocol or filesystem.

Well, thank both of You for a swift reply.

As I came here chasing the title of the thread, I was really not aware of dying protocols. Contrarily, I was wondering 'why so many to choose from'? And why one has to project Dataset share type if share protocols were meant to choose later?

To put this in my perspective, the idea was to gather TM backups from multiple users into single dataset, which I did by creating a separate afp share per user. And it works the way it is suppose to work, I guess. @anodos already wrote what is the more common practice in particular scenario, but I try to live it out in another thread.

The purpose of Dataset share type is still not very obvious when in comes to setting up FreeNAS machine, according to User Guide and FreeNASTeam channel on Youtube.

For instance, if I try to setup share for a Time Machine, FreeNAS® 9.3 Shares Overview and User Guide claims it must be AFP and run on Mac Dataset Share Type. As I read Your answer, @SweetAndLow, I am dying to know what is dying with afp and my setup? And why should I set Dataset Share Type to Mac at all then?

As well as for Plex media server dataset, commonly it is set to Unix Share Type, however, official exposé shares it via CIFS, though "it is slower than an NFS share due to the single-threaded design of Samba. It provides more configuration options than NFS and is a good choice on a network containing any Windows systems. However, it is a poor choice if the CPU on the FreeNAS® system is limited; if your CPU is maxed out, you need to upgrade the CPU or consider another type of share." – FreeNAS User Guide 9.10.

So, each source denies another. I know FreeNAS is not a "no-brainer" thing and creativity is more than mandatory. But the labyrinth of "reliability and doing it correctly" is about to leave me clueless.

Maybe someone knows the path?

Apparently, 9.10 latest stable.

 

[danb35]

Afp is dead probably best to just not use it.

No choice if you're using Time Machine; that must go to an AFP share. Otherwise I'd agree--for routine file-sharing with Macs, CIFS is just fine.

 

[Robert Trevellyan]

No choice if you're using Time Machine; that must go to an AFP share

Not strictly correct, but it is a lot more hassle over CIFS.

 

[Thinkcat]

So I gather that there is no single choice that would work for everything. At least Mac and Windows now agree that SMB/CIFS is the way to go. Don't they both use some kind of ACLs?

I'm abandoning AFP on one machine and migrating the stuff onto a CIFS share. It would be nice if I could use it from all three worlds (Mac, Win, linux).

Also, should I use Mac for the share type, even if I plan to share the dataset via SMB/CIFS?

 

[anodos]

So I gather that there is no single choice that would work for everything. At least Mac and Windows now agree that SMB/CIFS is the way to go. Don't they both use some kind of ACLs?

Yes

Also, should I use Mac for the share type, even if I plan to share the dataset via SMB/CIFS?

No

 

[bwanajag]

I'm brand new to FreeNAS and have not even acquired all the hardware to build my NAS. In reading through documentation on creating pools and datasets (and watching lots of Youtube videos), I came to question what to select for the Share Type. In looking at the documentation, it seems Share Type would be Generic or SMB. However, watching youtube shows that the Share Type options are Unix, Windows, and Mac. Having a mixed environment of three types (Windows, Mac, and Linux), I am confused as to which to select when creating a dataset - thus I found this thread. Would it not be more helpful (for new/home users) for the three options to be Unix, Windows and macOS, and AFP?

 

[SweetAndLow]

I'm brand new to FreeNAS and have not even acquired all the hardware to build my NAS. In reading through documentation on creating pools and datasets (and watching lots of Youtube videos), I came to question what to select for the Share Type. In looking at the documentation, it seems Share Type would be Generic or SMB. However, watching youtube shows that the Share Type options are Unix, Windows, and Mac. Having a mixed environment of three types (Windows, Mac, and Linux), I am confused as to which to select when creating a dataset - thus I found this thread. Would it not be more helpful (for new/home users) for the three options to be Unix, Windows and macOS, and AFP?

You will be using smb for your protocol so just choose windows as your dataset type.

 

[anodos]

You will be using smb for your protocol so just choose windows as your dataset type.

In 11.3 these are replaced with share type presets. Currently they're "Generic" and "SMB".

 

[phier]

hello,
i also chime in ... "Select the type of share that will be used on the dataset. Choose between Generic for most sharing options or SMB for a SMB share. Choosing SMB sets the ACL Mode to Restricted and Case Sensitivity to Insensitive. This field is only available when creating a new dataset."

Thats not so clear to me .. in that case i cant expose data for r/wopurposes via nfs on that dataset? Thanks