Want to Share Your Stuff with Mac OS X Server? The Basics of Share Points and Home Directories
- Telling Your Server How To Share with Other Macs
- Now That the Servers Ready to Share, Create Some Share Points
- Three Share Points that Apple Assumes You Need (But You Probably Dont)
- Making Share Points Behave
- Automounting Share PointsIts About More than Just Connecting Them
- Giving Permissions to Share Points and Files Within Them
- When Owner, Group, and Everyone Arent Enough: Access Control Lists
- Theres No Place Like Home, Even If Its a Home Directory Nowhere Near Kansas
- Configuring Home Directories
- Using Quotas to Keep Users From Storing Too Much Stuff
- When Do You Actually Build Home for Your Users?
- Securing Home Directory Access
- Making Users Feel More At Home By Altering the Home Directory Template
- Saying Goodbye to Users and Deleting Their Home Directories
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
For more information on the Macintosh, visit our Macintosh Reference Guide or sign up for our Macintosh Newsletter.
One of the primary uses of servers within a network is to host shared files. For some small offices or organizations, this task can be the only use for a server. Usually, however, the documentation for a server (be it the several volumes of PDFs that accompany Mac OS X Server or one of the books on the subject) can make deploying a simple file server (or learning how to manage one) seem like a daunting task. For those who simply need to understand the basics of file sharing using Mac OS X Server, this article walks you through both the underlying concepts and the actual steps involved in setting up file sharing and share points. Along the way, I’ll also discuss home directories—continuing some of the discussion of Apple’s Open Directory from my recent article "So You Want to Be a Mac OS X Server Admin? Understanding the Building Blocks of Open Directory and Mac OS X User Management."
Apple Filing Protocol (AFP), occasionally referred to as AppleShare, is the native file service for Macintosh computers. It is a protocol that operates over TCP/IP and AppleTalk. It is supported by, and is the default file service for, both Mac OS X and the classic Mac OS versions (although Mac OS 8 clients should have their AppleShare client updated to version 3.8.8, which can be downloaded from Apple’s support site, to interact properly with Mac OS X Server). Mac OS X Server supports AFP for accessing shared files over TCP/IP only, although it can support locating servers and share points using AppleTalk. AFP enforces access restrictions based on user account and group membership and supports Kerberos authentication for additional security and single-sign-on access to servers when used in an Open Directory environment.
To make share points and files available using AFP, you need to configure the AFP service using Server Admin. This needs to be done for any servers that will host share points, regardless of whether they are Open Directory servers or whether they are part of a shared directory services environment (Open Directory or other) or are standalone file servers. If share points hosted by a given server are meant to be accessed using user account information from a shared domain, they must either be a directory server for that domain (master or replica) or be bound to the domain. To use Kerberos authentication, they must also be joined to the appropriate Kerberos realm (which should occur when the server is joined to a shared domain).
Telling Your Server How To Share with Other Macs
To configure the AFP service, launch Server Admin and select AFP in the Computers " Services list for the server; then select the Settings tab at the bottom of the right pane of the window. After you configure the AFP service, click the Start Service button in the toolbar to enable AFP access, if the service is not running already (see Figure 1).
)
The General tab allows you to specify a logon greeting that is displayed to users when they connect to the server (logon greetings are not displayed for auto-mount share points, which we’ll discuss later) and to select whether the server will broadcast its name and availability using AppleTalk and BonJour/Rendezvous.
The Access tab settings offer you six options to control who can access AFP share points and some of the access methods:
- Authentication: This pop-up menu allows you to choose whether to use Kerberos for the AFP service. The options are Kerberos to requires Kerberos authentication, Standard to specify that Kerberos should not be used, and Any Method to allow Kerberos to be used when possible and non-Kerberos methods to be used when Kerberos is not an option (early Mac OS X versions do not support Kerberos, for example).
- Enable Guest access: When checked, users can log in as Guest. The Guest user does not require a password or any identifying information. Guest access is inherently insecure, but might be needed in situations where there are frequent shifts in who is accessing files on a network or when files need to be made available to anyone who sits down at a computer. Guest access can also be enabled or disabled for each share point you create (although it must be enabled for the AFP service for a share point to support it), which allows you to tighten the security of specific share points. You can further limit Guest access using share point and folder and file permissions. However, unless absolutely needed, my advice is to not use Guest access because in addition to its insecurity, it is difficult to identify who a Guest is. In a school situation, in which you need to grant generic access to all students, creating a generic student user or a generic user for each classroom or each workstation might be a better option because it allows you to at least have some trail to identifying who guest users are and to identify between them and what they are accessing.
- Enable secure connections: This option allows workstations to establish secure connections using the various encryption methods supported by Mac OS X Server and Open Directory for authentication and access to shared resources. As a rule, you should make use of this option at all times, particularly if you will support connections that do not make use of Kerberos (that is, connections from computers that are not part of a shared directory domain and as such will require users to transmit their username and password when they connect to the server).
- Enable administrator to masquerade as any registered user: This option can be considered somewhat controversial. When checked, it is possible for an administrator to log in as a user, using the user’s username but the administrator’s password instead of the user’s password. This has obvious privacy implications and you should specify in a company or school network or computer policy that you reserve the right to access user information before using this option (or you could find yourself in a legal battle). The other concern is that this feature does present an additional security concern if someone does gain access to an administrator password (though if that happens, you will probably have greater security issues to worry about). If you use this feature at all, my suggestion is to leave it disabled unless you are choosing to log in as a user for some explicit reason.
- Maximum Connections: These last two options let you define how many users can connect to a server using AFP at a given time. You can set a connection limit for all users (those with users accounts as well as Guest users) or for just Guest users. Limiting the number of connections can be used to improve server performance and security, but it raises the question of users being unable to access data that they need. As with many things, this is a balance you need to strike in your network. Generally, you can limit connections based on the number of users or workstations in your infrastructure (keep in mind, however, that some users might establish multiple connections to a server).
The Logging tab allows you designate what information is stored in the AFP service logs and how often those logs are archived. There are two AFP logs (and I suggest using both), one for file access and one for service errors—which is always enabled. Both logs can be viewed in Server Admin by selecting the AFP service and then selecting the Logs pane using the tab at the bottom of the window. To free up resources within Server Admin, you should select the option to archive logs (that is, only display the current logs in Server Admin and save the rest to dated files located in the /Library/Logs directory of the server’s startup drive).
The Idle Users tab for the AFP service settings determines how the server responds to connections where users stop interacting with files on the server. Each time a user connects to the server, the server creates and maintains a session for that user. While the session is open, the user can open files and modify them. The session is considered idle if the user stops opening, closing, or saving files or folders (although the user is still connected, the user isn’t doing anything with data on the server). While a session is open, it uses server and network resources, even when it is idle. Therefore, a large number of idle sessions can degrade performance. Also, you cannot back up files that are open (and users can have open files while being idle). If a session is terminated while a user has open files that they have made changes to but not saved, the file is closed and those changes are lost. The Idle Users tab gives you some options in how to deal with users that have open and idle sessions with a server:
- Allow clients to sleep X number of hours: When this option is enabled, the server will terminate the network connection to the workstation but maintain the user’s session for the specified number of hours (the default is 24). This frees up the network resources (but not the server resources) used by the session and can keep a user from losing changes they made to files on the server. After the number of sleep hours you specify has elapsed, the session is considered idle.
- Disconnect Idle users after X number of minutes: This option allows you to automatically disconnect users who have idle sessions. This can free up server resources (as well as network resources), but if users have unsaved changes, they will be lost. You can also specify exceptions to the automatic disconnect for users who are Guests, Administrators, Registered users (non-Guest users, those that have logged in with a user account), and Idle users who have open files. Finally, you can type in a message to be displayed when a user is disconnected.