Troubleshooting File Services

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.