Join Mike Danseglio for an in-depth discussion in this video File sharing in Windows Server 2012, part of Windows Server 2012 Active Directory: File System and Storage.
- So file sharing in Windows Server 2012. Largely if you understand file and folder permissions, NTFS permissions, file sharing is pretty trivial. It's pretty straight forward with one caveat, one special thing you want to know about. I'm going to show you a little bit of everything, but a lot of that one special bit. Creating a file share is actually pretty darn easy in Windows Server 2012. It's one of the very, very few things that's on by default, and I don't say that lightly.
There's very little that's actually on by default in Windows Server 2012, but this thing is. It's almost trivial to create a file share, or shared folder. Depending on what part of the documentation, or what part of the interface you're looking at when you do it, it's either called a shared folder or a file share. I want to make sure to mention that the file and storage services role is required before you create a file share or a shared folder, however, it's on by default.
It's the only role that's installed by default with Windows Server 2012. So, that's kind of easy, kind of trivial. Recommended however, domain membership. If you're going to join a domain and share files or folders out, or if you have a domain in place you probably do want to get that set up first. You want to actually create whatever users or groups are going to access this shared folder before you start sharing it. You can certainly modify this stuff later, but ultimately coming up with a bit of a plan, some idea of who's going to have access or not have access to shared resources.
For example if you're going to share out un-filed intellectual property patents, you want to make sure that that share is only accessible by people that have permissions to access un-filed patents. That's kind of a critical bit, so just having some idea rather than just everyone full-control, or everyone read-only before you get started. And of course all of these things are changeable once the share is in place, but it's nice to know up-front what you're setting up, have a bit of a plan before you get started.
The process is pretty straight-forward though: create a folder, assign permissions to the folder, NTFS permissions, and then actually create and configure the share. The share actually has a few properties, most of which are pretty obvious. I've taken a screen shot here, and I can do it live, but there's actually almost no need to do it live at this point. The screenshot shows almost everything you want to see, this concept of advanced sharing is just the nice way on the title of saying, "Not simple sharing." There is a concept of simple sharing in Windows Server 2012 that I will actually show you, I personally turn it off every single time, but I'll show you what it looks like.
Having the ability to add more than one share name to a particular share, so one folder can actually have multiple share permissions, multiple shares, multiple presence on the network. That's actually kind of useful, kind of nice where you can have different people come in, with different levels of permission. That's pretty darn useful. Setting the number of simultaneous connections, if you want to throttle it down for either licensing or band-width utilization, kind of useful. Permissions, which is essentially almost the same, not quite the same, but almost the same as NTFS permissions and I'll show you what those are.
And caching, this concept of offline files. I'll show you those in just a moment that's actually a special one, an interesting one that definitely deserves a bit of conversation. But that's what you set up. Do you have to set those up? You don't have to set those up, you can actually use what's called simple file sharing, and it will do all of that for you. I prefer a little bit more granularity, but let me show you the basic one, the simple version of file-sharing to see if you like that.
So, I'll do that over here, I have a folder off the route of C called "Public folder." I'm going to right-click it and chose "properties," and under sharing there's actually two buttons, "Share", and "Advanced sharing." The first button here, "Share" is called, "Simple file sharing," Simple file sharing, hmm. Let's see if I can define it without using the correct word. It is an easier way to create a shared folder on the network.
That's not too bad, it's simple file sharing meaning all they're doing here is showing you the basic stuff, what you need to do in order to share out a file or a folder. Right here it just gives you the default permissions, you click "Share" there you go it's done! It's got this cute little email link, so if you're running Outlook on your server, actually if you're running Outlook on your server you should probably just go ahead and un-install Windows Server 2012. You shouldn't be running email programs on Server anyway, but you can actually take this UNC path and share it out, copy it, send it to friends, send it to co-workers, whoever you want it to go to.
All of that kind of stuff. So that's it, that's simple file sharing, it's done. However, this button here is the more interesting button, this is the button that you can actually see over there in the screen shot, same stuff. It's got the same level of granularity, as far as permissions go, as file and folder objects do in NTFS. This permissions tab here allows me to set the ACL's or set the ACL rather, which is a group of aces for the share itself.
Not for the files, not for the folders, but for the share. And that's where this special rule will come in, in just a moment that i'll show you. I can actually add groups, I can remove groups, I can change all the permissions right here. And then I can add seperate shares if I want to share more than once. The other bit that I do want to show you is this concept of off-line files and folders. This concept of off-line files and folders allows Windows clients to actually cache out files and folders, or anything that's on that share, which is kind of useful for remote users, for roaming users, things like that.
Windows kind of has an honor system, to some degree, to be honest about this, where the permissions on the share tell the client should you cache or should you not cache, or "You should cache," or "You should not cache the contents." That doesn't mean that if you're using a third-party share client like Samba, something like that that it can't actually suck all the data down and then just cache it on it's own. This is to some degree an honor system, but it's kind of useful. Kind of interesting to know that this is how off-line files are created, or configured rather.
I'm going to cancel out of that, and I'm going to go ahead and "OK" and we'll go ahead and close this. You can actually see before I close it, this is shared as, "//usshqserver2/publicfolder", and now I would see that show up on the network. That's all it takes, fairly straightforward, right? You would think, but of course I'm tricking you because nothing is that straightforward, there's always some special thing here. Not so much that the NTFS permissions look the same, but aren't quite the same, that's actually not the most interesting bit.
You can take a look at the read/write kind of permissions out there, execute permissions out there, they're pretty simple, pretty straightforward. They're even simpler than NTFS permissions actually. What's interesting is this special rule. This special rule is absolutely critical to figuring out why users can or cannot get to resources on a share. Because we now have permissions, and i'll go back to public folder for a minute, we have permissions on...
Let's say a user is trying to get to this file here, this "supersecretdata.txt" through a share on the network. The permissions that Windows is going to have to go through in order to grant that user access is: the share permission first, then the folder permission second, then the file permission third, to figure out whether the user has access to this object or not.
Remember, everything in NTFS has permissions set on it, file shares are NTFS objects just over there instead of over here, on the network instead of on the local hard-drive. All of those same checks have to happen. And the trickety-bit is that one takes precedence over the other. The most permissions that a user can get on an object when they connect over a file-share, is the least permissions.
Meaning, I think the best way to think of it is when you look through the keyhole at a room, there might be a 20 foot by 20 foot wide room and, wow, It's now I guess the 1880's because there's still the concept of a keyhole. Let's go back to the 1880's and I'm looking through a keyhole into a room, and it's a giant room a large room, all kinds of space in there, all kinds of different objects, the most I can see is narrowly constrained by what's in the field of vision of the keyhole.
And then anything that I can see through that keyhole has to be unobtrusive, I have to be able to have a direct line of sight to that object. So, if there's some object maybe five feet in front of the key-hole and another object ten feet past it, I can only see the first object. But I can't exceed the field of vision of that key-hole. It's a similar kind of thing with share permissions, the most amount of access I can have to file and folder objects through a share is constrained by the most permissions I get at the share level.
So, if the share level permissions are let's say read-only, the most access I'm going to get when I connect to those objects through the share is read-only. I get that question all the time, "Mike why can't I write to this file?" "Why can't I save this file?" And the person is looking at the NTFS permissions of the file itself or the folder itself, but not the share permissions. If they're not exactly the same there is always going to be a discrepancy, there is always going to be a change there.
That's the special rule you need to remember, is the least effective permission will always win. In practical use it's almost always that the share itself is constrained. The share winds up being read-only, but somehow an administrator thinks that they should get read/write access, or delete access, or some other kind of access through that share, even through the share is set as "Read-only," and that's never, never, never, going to happen. That's the most important thing I can tell you about shares.
It's actually pretty simple, it's pretty straight forward. It's almost a breeze to get this file-share stuff running, to make it work correctly, as long as you plan the permissions, and ensure that you check the one special rule about "least access." Because that's always going to take precedence.