- Challenges of File Sharing
- Different Protocols for Different Clients
- Planning File Services
- Using Apple Filing Protocol
- Configuring Apple File Service
- Monitoring AFP Activity
- Using Windows File Service
- Configuring Windows File Service
- Configuring Access and Starting Windows File Services
- Using NFS Share Point Access
- Configuring NFS
- Using FTP File Service
- Configuring FTP Service
- Network-Mounted Share Points
- Preparing for a Network Home Folder
- Configuring Network Mounts
- Controlling Access to Shared Folders
- Troubleshooting File Services
- What Youve Learned
- References
- Chapter Review
This chapter is from the book
This chapter is from the book
This chapter is from the book
Troubleshooting File Services
Whether you’re using AFP, SMB, NFS, or FTP, troubleshooting file services on Mac OS X Server typically involves the following considerations.
- User access: What users or groups should have access to the specific files and folders on the server, and are their appropriate permissions set correctly?
- Platform and protocol access: From what clients are users trying to access the server, such as Mac OS X, Mac OS 9, Windows, or Linux systems? What protocols are they using when accessing the server?
- Special needs: Are there any special circumstances, such as users’ needing concurrent access to files or access to files in a nonnative format to the system they are using?
- Concurrent access: Is there a possibility that in your users’ workflow, there could be multiple clients simultaneously accessing the same files, regardless of the file-sharing protocol(s) being used?
For troubleshooting access settings, you will want to test access by using the Effective Permissions Inspector and by logging in from remote clients. Here the biggest issue will be starting with an appropriate logical group structure and maintaining it over time.
While the different sharing protocols (AFP, SMB, FTP, NFS) support multiple platforms, it can be tricky to provide concurrent access to the same files or when platform-specific issues come into play. Concurrent access means that multiple users are trying to access or modify the same files at the same time. Many times this is dependent on the specific cross-platform applications knowing how to allow multiple users to access the same file. Because Mac OS X Server includes support for ACLs and these ACLs are compatible with ACLs from the Windows platform, permissions mapping between Windows clients will be in line with what Windows users expect to see. Prior to Mac OS X Server v10.4, this was not necessarily the case.
Another consideration is if the clients will be storing forked files on the share point. If you use Mac OS Extended for an SMB share point or an NFS export, files created or copied onto the server from the client side will have shadow files instead of resource forks. These files will not look right when viewed from the server. Conversely, files created from the server side will look wrong from the client, which cannot see the resource forks.
Case-Sensitivity Issues in File Sharing
Case sensitivity becomes an issue if you are copying files between two computers and only one of them has a case-sensitive file system. Beginning with Mac OS X Server v10.3, drives can be formatted as Hierarchical File System Plus (HFS+) case-sensitive volumes. Suppose you have two files, Makefile and makefile, in the same folder on a case-sensitive Mac OS X server. If you were to copy those files to a Mac OS X client computer, which is by default not case sensitive, you would run into problems. The operating system would attempt to overwrite one file with the other. When you copy files from a case-insensitive file system to a case-sensitive file system, you might have a problem with executable files. For example, suppose you had an executable script called Runscript on your case-insensitive file system. If you were to copy that file, without altering its name, to a case-sensitive file system, users would be able to run it from the command line only by typing Runscript. This could be problematic if the documentation called for typing runscript (all lowercase).
You need to be aware of the issues associated with case sensitivity now that Mac OS X Server can easily be configured to be case sensitive, while the Mac OS X client cannot. Not much can be done to synchronize case-sensitive and case-insensitive systems. You need to work around the incompatibility. Given that NFS, FTP, and AFP are case-sensitive protocols, mounting a share point using any of these protocols enables you to see the different case-sensitive files and download whichever one you’d like.
More specifically, SMB does not seem to be a case-sensitive protocol, but it has a distinct preference for uppercase filenames. For example, if your share point contains the files Runscript and runscript, and you use SMB to download either of these files to the client, only Runscript is downloaded, whether you asked for Runscript or runscript. Similarly, if you try to move runscript to a different folder in the share point, Runscript is moved, not runscript. Also, if you upload a local file named runscript to an SMB share point that already contains Runscript and runscript, you are prompted to replace the existing file, but then the operation fails and Runscript is deleted.
Here’s what happens: When you attempt to copy runscript to the server, SMB detects the existence of a file with the same name and asks if you want to replace it. Once you click OK, SMB deletes the file Runscript and then attempts to copy runscript to the server. However, that operation fails because runscript still exists on the server. If you try the upload again, however, it succeeds, because now there is only one runscript on the server. When you tell the server to replace the file, it does so without confusion.
A Comparison of File-Sharing Protocols
This table gives a short comparison of the file-sharing protocols you have seen thus far. There really isn’t one best protocol. Instead, think of the protocols as different tools at your disposal to give different types of access.
|
AFP |
SMB |
NFS |
FTP |
|
|
Native platform |
Mac OS |
Windows |
UNIX |
Multi-platform |
|
Security |
Authentication is normally encrypted |
Authentication is normally encrypted |
Authentication only if using Kerberos |
Uses clear text passwords |
|
Browsable |
Bonjour |
NetBIOS |
Bonjour |
Bonjour |
|
Example URL |
afp://server17.example.com/SharePoint |
smb://server17.example.com/Share |
nfs://server17.example.com/Volumes/Data/ |
ftp://server17.example.com nfs_share |
AFP and SMB are both full-featured file-sharing protocols with reasonably good security.
NFS (without Kerberos) is not as secure as the other protocols, but it is very convenient for UNIX clients. Be careful before you “export” (share) a volume over NFS. With a Mac OS X server and a Mac OS X client, NFS volumes are browsable in Connect to Server; that is, a user can find them by browsing through a list of servers in the Connect to Server window.
FTP is useful because it offers maximum compatibility. However, FTP also offers a minimal feature set, and its passwords are sent over the network as clear text unless you are using the Kerberos option and a supported Kerberos FTP client—something the Mac OS X Finder lacks.
Mac OS X supports secure File Transfer Protocol (SFTP), a secure alternative for FTP that uses SSH to encrypt the FTP connection. Of the four file-sharing protocols, only AFP has simple built-in support for encrypting connections. If you’re in a fully Kerberized environment, you can also use NFS in an encrypted fashion, but you still must deal with its other shortcomings.