Once a server has been installed, it’s time to start setting up the service or services that run on it. And sharing files is the most important aspect of most servers. File sharing is used to provide a centralized repository for any type of file, whether a presentation, homework, a spreadsheet used to track bills, or even a shopping list to help you remember the milk. You can then control who can open, edit, or delete files to keep each user from having inappropriate access to files and folders that are shared from the server.
There are two aspects of file sharing that are important to consider. The first is controlling access to who can do what by managing the permissions on the files. We will cover permissions first, as files do not need to be shared until the appropriate permissions have been set. The second aspect of sharing files is actually enabling the file shares and configuring settings specific to those shares.
Once we have covered setting up the server itself, we’ll move on to connecting to the server from client systems. These systems include Mac OS X (Lion), iOS (iPad, iPhone, and iPod Touch), and even Windows. Each of the supported platforms uses a different protocol (by default) to connect to the server. Windows uses SMB (Samba), Mac OS X uses AFP (Apple File Protocol), and iOS uses WebDAV (Web-based Distributed Authoring and Versioning), which is based on the classic HTTP protocol so heavily used for web traffic. Finally, we’ll look at Time Machine Server in this chapter. Time Machine Server is, at its core, a file share. But first, let’s get the data ready to be shared to client computers by configuring the appropriate permissions.
Many environments just need to give everyone access to files and folders. This type of configuration is simplistic and typical in smaller environments. As the number of users and files grows, so too grows the complexity of the data shared by the server and the permissions for who gets access to that data. Luckily, Mac OS X comes with plenty of tools for managing who can access what, and more specifically, how that data can be accessed.
Permissions should always be configured for each user to have the least required permission to any file. This means that permissions should not be provided to any data that a user does not explicitly need access to. The easiest way to do so is to simply not include any user or group to have access to a directory that doesn’t absolutely require access. Users that do not have access to the root level of a share cannot then traverse deeper into the hierarchy of files in the share. Managing access to the root of each share is done using the Server application, as discussed in Enabling Sharing later in this chapter.
Once a share is created, managing permissions to files within that share is primarily done using the Finder or the Server application. Using the Command-I keystroke, or clicking on any directory or file and then choosing Get Info from the Finder’s File menu brings up the Info screen. Here, permissions to files can be configured using the Sharing & Permissions section, accessible using the disclosure triangle for that section. Configuring permissions on servers and clients can be done from the Finder. But on servers, administrators can change POSIX settings more easily using the Server application.
To configure permissions using the Server application, click on the server name under the Hardware section of the sidebar. Then click on the Storage tab and click on a file or folder to change the permissions of. Then, using the cogwheel icon’s contextual menu, click on Edit Permissions. As you can see in Figure 3-1, each user or group that has access to a given directory is shown, as well as what kind of privileges. The bottom three items are POSIX permissions, and all items above those are Access Control Lists, or ACLs.
Portable Operating System Interface for Unix (POSIX) permissions are standards that dictate how Unix-based operating systems should function. POSIX permissions are how OS X refers to its legacy file permissions that allow OS X to be part of the Unix family of operating systems. As mentioned, the last three items listed in the Edit Permissions screen are the POSIX permissions. These include an Owner, a Group, and Everyone. The owner can be any user on the system, the group can be any group on the system, and Everyone includes all authenticated users.
The permissions for Owner, Group, and Everyone are set using the drop-down menus next to each entry in the Finder Info screen. The settings for each are:
- Read & Write
Users have full permissions to edit, read, and even delete files.
- Read Only
Allows users to read items in the directory or open a file, but not to edit the contents. A great example of this is forms and templates. In many cases, forms and templates should only be Read & Write for a select group, such as Human Resources, and should be Read Only for everyone else.
- Write Only
Allows users to write to the folder, but not to read the contents, often used for drop boxes. For example, homework submission should be configured in such a way that a teacher or parent can read and write to the folder (thus being the Owner or Group) and Everyone can Write Only, so that students cannot see each other’s work.
- No Access or None
Available only for Everyone from the Finder, No Access means users not in the Owner or Group section (or an ACL, which will be covered in the next section) have no access to even see contents of directories.
Changing permissions for a file or folder is as easy as clicking
on the entry for Read & Write, Read Only, or Write Only and
selecting the replacement. While the POSIX permissions that can be
configured from the Finder are somewhat limited, the command-line
options available allow for much more granular permissions. For example,
using the chmod command, execute only can be
configured or No Access can be applied to groups and even owners of
files and folders.
The entries for Owner and Group are typically set when a share is created. These can also be changed at any point using the Server app or the command line. To change the name in the Server app, double-click on the entry for the Owner or Group. Then type the short name of the Owner or Group you would like to use. Click out of the screen to then commit these changes and the new settings will be effective immediately. Use the cogwheel icon again to bring up the Propagate Permissions option, in order to push these changes down to subfolders and files.
The chown command is used to set either the
Owner or the Group. While the command line may seem daunting at first,
few commands are easier than chown. To change the
owner, use chown followed by the user or group who
should become the Owner or Group and then the location to change the
ownership for (e.g., the file or directory). For example, to change the
Group for /Shared/Assignments to a group called
Teachers (where Teachers is the short name for the group), use the
following command:
chown Teachers /Shared/Assignments
Or if there are already items in the directory that also need
their permissions changed, add the -R option to
recursively make these changes:
chown -R Teachers /Shared/Assignments
If you get any errors indicating that the operation is not
permitted, then you will need to run the command with elevated
privileges, which means you’ll need to preface it with the
sudo command:
sudo chown -R Teachers /Shared/Assignments
Once the permissions have been set for a single folder, you could also elect to make those changes recursive using the Info screen in the Finder. To do so, browse to the directory in the Finder, use Command-I or the Get Info option under the File menu, and then (provided the permissions are set as intended), click on the icon of the cogwheel to bring up a menu. In that menu, click on “Apply to enclosed items…” and provide the administrative username and password when prompted.
In case you’re not interested in using the command line to manage POSIX permissions, consider getting an application called BatChmod. BatChmod gives you the ability to manage POSIX permissions as granularly as you would like in a simple to use graphically appealing interface. BatChmod an be obtained at http://www.lagentesoft.com/batchmod/index.html.
Now that we’ve looked at managing POSIX permissions, let’s look into ACLs, which most administrators will use more, given their flexibility. ACLs are a slightly different beast. Each entry in the ACL is known as an access control entry (ACE). You can have a lot of these entries, whereas you can only have the three objects for POSIX permissions. ACLs also provide a lot more types of permissions, including each of the following for the user or group specified in the ACE for files and/or folders:
- Administration
Settings that allow users to change permissions of objects themselves
- Change Permissions
Can change permissions
- Change Owner
Can change the owner (therefore taking ownership)
- Read
Settings limiting access to read options
- Read Attributes
Can read POSIX attributes (e.g., modification date)
- Read Extended Attributes
Can read extended attributes (e.g., metadata such as quarantine status)
- List Folder Contents (Read Data)
Allow listing the contents of a directory or file
- Traverse Folder (Execute File)
Allows opening the folder in order to get to a subfolder as well as executing any files in the folder as a program
- Read Permissions
Allow reading permissions that are applied to the object
- Write
Settings limiting access to write options
- Write Attributes
Allows modifying the file or folder (e.g., modification date)
- Write Extended Attributes
Allows writing extended attributes (e.g., metadata such as quarantine status)
- Create Files (Write Data)
Allows creating files inside the directory
- Create Folder (Append Data)
Allows creating a new directory inside the directory
- Delete
The right to delete the object and delete subfolders
- Files
The right to delete objects within the object
- Inheritance
Settings that control how permissions are applied to new objects
- Apply to this folder
ACEs are applied to the directory
- Apply to child folders
ACEs are applied to subfolders but not to the directory
- Apply to child files
ACEs are applied to files within the directory
- Apply to all descendants
ACEs are applied to all new objects within the directory
For each entry, select the minimum permissions required for each user or group. Make sure to use groups where possible (even, in some cases, if there is only one user in a group). Using the Full Control option in the drop-down list will enable all of the checkboxes, allowing users who have Full Control to do anything they like with the files and folders. By using a few groups, you can then very granularly limit access to files and folders. For example, let’s say you have a group called Teachers, another called Students, and yet another called Staff. Let’s say you want Teachers to have Full Control over files, Students to have Read Only access, and Staff to have access to Create but not Delete. You could easily achieve that with three ACEs, checking the appropriate boxes for each group provided.
Note
Recursively changing permissions does not remove ACEs from items
further down in the hierarchy that aren’t a collision with new items
being propagated. If a hierarchy becomes too complicated and you just
want to remove all ACEs and start anew, use chmod
with the -R and -N options
followed by the directory path, and all ACEs will be removed from that
directory as well as all subdirectories:
chmod -RN /Shared/Homework