Mac OS X Server 1.x: Mac OS Compatibility (MacOS.app) v2.2 Release Notes

This document describes the Mac OS Compatibility environment shipped with Mac OS X Server 1.1. This environment is implemented by the MacOS.app application, sometimes referred to as the "Blue Box".

Note: This document was installed by Mac OS X Server in /System/Documentation/Read Me For a list of other release notes see article 30925: "Mac OS X Server: Release Notes"
Note: This article pertains to Mac OS X Server versions 1.x, which were released prior to May 2001.

Contents

Overview

MacOS.app, sometimes referred to as the "Blue Box", is a high-performance, high compatibility environment for running Mac OS software within the Mac OS X Server operating system.

High compatibility is achieved by running Mac OS essentially unchanged in a virtual environment, which appears to be a new Macintosh hardware model. Because of this, the vast majority of Mac OS applications, utilities, extensions and software drivers just work. Software that directly accesses hardware, uses undocumented internal APIs of the Mac OS, or relies on Mac OS managers not yet supported by this release of MacOS.app is not expected to work.

The Mac OS managers not currently supported by this release are those generally associated with hardware not yet fully supported by Mac OS X Server. Such missing functionality is explicitly listed in this document and will likely be provided in subsequent releases of MacOS.app.

This release of MacOS.app comes with Mac OS 8.5.1 and will support future versions of Mac OS that have not shipped as of this writing. Previous versions of Mac OS are not supported, and MacOS.app will not allow them to run.

MacOS.app allows you to use your current Mac OS applications to "live" on Mac OS X Server, to explore its new capabilities while preserving your current Mac OS environment.

You are encouraged to read these release notes before running MacOS.app. If you just can't resist, at least read the following "Quick Start" section.

Quick Start

To start MacOS.app, choose Mac OS in the Mac OS X Server Apple menu or double-click on "/System/Applications/MacOS.app" in the Workspace File Manager. You may also want to drag an alias onto the Workspace for quicker access to MacOS.app. It is best not to launch MacOS.app from a Terminal window, since it will not result in a clean MacOS.app shutdown when logging out from the Mac OS X Server's Workspace.

The first time you launch MacOS.app, a private Mac OS 8.5.1 startup disk image (called StartupDisk.img) will be created. The language of the image will be selected based on the Localization settings from the Preferences application and the MacOS.app languages that have been installed. The selected image will be copied and uncompressed into /Local/Library/MacOS/Users/. This process will take a little time and is accompanied by a dialog box with a progress bar. At the end of creating the startup disk image, a virtual PRAM file called "PRAM" will also be created in the same directory.

Choosing Shut Down from the Mac OS Finder's Special menu will quit MacOS.app. Similarly, choosing Restart will quit and re-launch MacOS.app. You may also use the Power key, which will bring up the standard Mac OS "Shut Down / Restart" dialog box.

To switch between the Mac OS and Mac OS X Server environments, use the Application menu at the far right of the menu bar. In both MacOS.app and Mac OS X Server, this menu has been extended to list all applications running in both environments, grouped by environment. If you choose an application that is running in the other environment, you will be switched to that environment and the selected application will be activated.

There is a special item in the application menu of each environment that will switch you to the other environment and bring you back to the last application you were using in that environment. That item is called "Mac OS X Server" in the Mac OS environment and "MacOS" in the Mac OS X Server environment.

The following special keys combinations are available when you are in the Mac OS environment, and supersede any Mac OS use of these key combinations:

Command-Return is a shortcut for choosing "Mac OS X Server" from the application menu. Since this may interfere with some applications that use this combination of keys, you may disable it, as discussed under "User Input" in the "Bugs and Compatibility Issues" section.

Command-Shift-Q will force-quit MacOS.app. This would be equivalent to pulling the power plug out of the wall on native Mac OS and should only be used when Mac OS is hung.

All other Mac OS special keys (e.g., Command-Power for NMI - to enter MacsBug) function as expected.

Before installing software, read the section "Use of Disk Image Files", under "Working with Disk Image Files".

System Requirements

The minimum recommended RAM for running Mac OS X Server with MacOS.app is 64 MB.

Each user running MacOS.app on this machine will require a minimum of 175 MB of disk space for the Mac OS 8.5.1 startup disk image. The Japanese localized startup disk image requires approximately 200 MB of disk space.

Installation

MacOS.app is installed as part of the standard Mac OS X Server installation. Earlier versions of MacOS.app are not compatible with Mac OS X Server.

The installation consists of the following installed items:


This release note document.
The application directory contains the executable file (MacOS), supporting resources and compressed localized Mac OS disk images. The particular localized disk images installed (of English, French, German and Japanese) will depend on your language selection(s) when you install Mac OS X.
A command-line utility to create new disk image files (discussed under "Working with Disk Image Files").

Features


MacOS.app currently supports Mac OS 8.5.1. The supplied StartupDisk.img files contain complete default installations of Mac OS 8.5.1 except for Apple Remote Access and Text-to-Speech. These were omitted to save space and because they rely on features not yet supported by MacOS.app.

Do not attempt to install previous versions of Mac OS. Future versions of Mac OS are likely to be directly installable by running their installer in MacOS.app.


MacOS.app uses a new method for virtual memory, taking advantage of Mac OS X Server's VM system. This method, called "Sparse Virtual Memory", allows application heaps to be protected from each other with "guard" pages of unmapped memory. In addition, it allows a large number of applications to be launched, using disk space for memory as it is needed. The total virtual application memory available is 1024 MB.

MacOS.app always runs on top of Mac OS X Server's Virtual Memory, but Mac OS VM will appear to be off to applications.


In native Mac OS, an application's memory heap comes out of the same memory area as temporary memory. Since some applications allocate large fractions of available temporary memory, MacOS.app does not offer the entire unused portion of its 1024 MB sparse virtual address space as temporary memory. Instead, the temporary memory heap is created at startup time, with the size determined by the machine's available physical memory, with a minimum size of about 16 MB. Some applications may require a larger amount of temporary memory in order to run properly, and you can allocate additional temporary memory by setting SysZoneMemorySize to the desired size. For example "defaults write MacOS SysZoneMemorySize 0x10000000" will set the temporary memory size to approximately 256 MB. You may notice this difference in the Finder's "About This Computer" dialog box. In native Mac OS, the first bar (labeled "Mac OS") shows the amount of memory allocated to Mac OS and is usually almost fully in use. In MacOS.app, this bar includes the memory allocated to Mac OS plus the temporary memory allocation. On machines with a large amount of physical memory, this bar will be significantly larger.
Throughout this document, "HFS(+)" is used as an abbreviation for "HFS or HFS+". HFS is also known as "Mac OS Standard Format" and HFS+ as "Mac OS Extended Format".

MacOS.app supports file systems on nearly all kinds of disk devices that are supported under the native Mac OS. These include, but are not limited to floppies, CD-ROMs, hard drives, and disk image files stored in the Mac OS X Server file system (UFS). Both SCSI and ATA/IDE (including ATAPI) drives are supported.

Disks can be accessed in one of three modes: Shared, Exclusive, or SCSI. Not all disk modes are available for all disks. The default access mode is Shared mode, except for disk images (which are always accessed in Exclusive mode). In order of highest-to-lowest interoperability with Mac OS X Server applications, the modes are Shared, Exclusive, and SCSI. Conversely, the modes in order of highest-to-lowest compatibility with Mac OS applications are: SCSI, Exclusive, and Shared.

Thus, there is a fundamental tradeoff involved with choosing which mode to use to access a disk. Shared mode was chosen as the default access mode because it provides a high enough level of compatibility to support typical productivity applications, while at the same time permitting access to the same disk via Mac OS X Server applications.

For more information, see the sections entitled "Disk Access Modes" and "Disk Drive Support".


MacOS.app currently supports basic Copy and Paste between Mac OS and Mac OS X Server applications.

Text can be copied (without style information) back and forth between the two kinds of applications. This includes some support for two-byte characters. See the "Bugs and Compatibility Issues" section for more details.

Pictures ('PICT') can be copied from Mac OS to Mac OS X Server applications, but are converted to RTF, which cannot be copied back to Mac OS. Many more data types are expected to be supported in future releases of MacOS.app.


MacOS.app supports Open Transport AppleTalk and TCP/IP networking using built-in Ethernet and any PCI Ethernet devices supported by Mac OS X Server. LocalTalk (AppleTalk over serial ports) is not supported. As with native Mac OS, AppleTalk networking is active by default if connected to a network.

AppleShare Client as well as Personal File Sharing, AppleShare Server and AppleShare IP Server are fully supported by MacOS.app. Personal Web Sharing is also supported.

Since Mac OS uses a different networking model than Mac OS X Server (Open Transport vs. Sockets), you must use a separate IP address for MacOS.app TCP/IP from that used by Mac OS X Server. This is best accomplished by using a static IP address in the TCP/IP control panel (or by using MacIP - IP over AppleTalk). In previous versions of MacOS.app, when the same IP address was used for Mac OS X Server and MacOS.app, Open Transport reported an error message indicating the reason TCP/IP networking is not available. If the same IP address is used in the present versions of Mac OS X Server and MacOS.app, Open Transport TCP/IP will silently be disabled.


MacOS.app partially supports the PCI native driver model. This means that the name registry, DriverServicesLib, and associated libraries are present. However, the Mac OS device tree is currently empty, so no 'ndrv' drivers are loaded.
Unlike Mac OS X Server, MacOS.app can change color depth on the fly and supports multiple monitors in color depths of 8, 16, and 24-bit (256, "thousands" or "millions" of Colors or Grays). However, if Mac OS X Server is in grayscale mode, then MacOS.app will not allow depth changes.

Because of limitations in Mac OS X Server, MacOS.app cannot change resolution (size and scan rate). The resolution must be changed in Mac OS X Server's Preferences application and the changes take effect after logging out of Mac OS X Server.

MacOS.app supports multiple monitors. However, you may set it up to use only one monitor on a multiple-monitor system. MacOS.app assigns the number 0 to the main monitor (the one with the menu bar). Additional monitors are assigned the numbers 1, 2, etc. Setting the Mac OS X Server user preference "MonitorSelect" for MacOS.app to a value that indicates that monitor's assigned number will cause MacOS.app to only use that monitor for displaying video.

For example, from a Mac OS X Server Terminal window:


means only use the main monitor and
means only use the second monitor.
AppleEvents and AppleScript are supported as usual within MacOS.app and from MacOS.app to scriptable Mac OS X Server applications.

For Mac OS X Server applications to be scriptable, they must use the Scripting Framework. Developer documentation on the use of this framework can be found in /System/Documentation/Developer/YellowBox/ReleaseNotes/

The Script Editor in MacOS.app can target applications that are running in the Mac OS X Server environment. On the local machine, targeting these applications is done the same way that targeting Mac OS applications is done.

For example, if you have a Mac OS X Server application named Sketch, you would target the application with standard AppleScript syntax:

If you are targeting Mac OS X Server applications on other machines, the syntax is slightly different and uses a semicolon between the application name and the host name: The normal Mac OS syntax to target remote Mac OS X Server applications: is not supported in this release.

The MacOS.app Script Editor cannot get the dictionary information for a Mac OS X Server application in Mac OS X Server 1.1. This functionality will be added in a later release.

By default, Scripting between two machines is turned off for security purposes (similar to Mac OS Program Linking which is turned off as the default). The following information will help you turn on remote AppleEvents and remote AppleScripting.

The remote scripting default is called NSAllowRemoteAppleEvents.

It can be set from a Terminal window like this:

It could also be turned on only for certain applications as follows: An API for using AppleEvents outside of AppleScript in Mac OS X Server applications has not been provided in this release.
Sound output is fully supported by MacOS.app, although breakup may occur during times of heavy CPU usage or memory paging. Occasionally, this may result in sound going silent altogether until the application using sound quits or MacOS.app is restarted. Playing sound in Mac OS X Server and MacOS.app simultaneously will have unpredictable results.
The Mac OS SCSI manager is partially supported in this release. It can be used via SCSI Mode for disks, as discussed in the section "Disk Access Modes", and to access non-disk devices (such as scanners and tape drives) which are not in use by Mac OS X Server.

Both the original SCSI Manager and SCSI Manager 4.3 are supported with the following limitations:

Disk Access Modes

The sections below describe the tradeoffs among the three access modes: Shared, Exclusive, and SCSI. If you are just running Mac OS productivity applications, you should not need to switch the access mode for any of your disks or partitions. However, in case you need to run disk utilities - such as Disk First Aid, Disk Copy, or Drive Setup - you may need to (temporarily) switch the access mode of one or more of your disks or partitions. The "Blue Volume Mount Options" control panel is provided to allow you to set these access modes for individual disks and disk partitions. It is described below, after the explanations of the three access modes.

You can determine in which mode a volume is being accessed by selecting it in the Finder and invoking the "Get Info" command from the "File" menu. The dialog that appears includes a "Where" string that describes the mode in which the underlying disk is currently being accessed, along with an indication of the physical disk to which it corresponds. Disks accessed in Shared mode will have "Shared" in this string. Similarly, disks accessed in Exclusive mode will have "Exclusive" in this string. Disk image files (which are always accessed in Exclusive mode) will list the pathname of the disk image file. Disks accessed in SCSI mode will have a string identical to the one they would display if running native Mac OS; typically this string gives the SCSI Bus number and SCSI device ID of the drive.

For disks accessed in Shared or Exclusive mode, the SCSI bus and ID (or ATA/IDE ID) are not given; instead, they are identified in the "Where" string by their Mac OS X Server device name. In order to understand how Mac OS X Server names disk devices, you will need to consult the documentation for Mac OS X Server. Briefly, SCSI (and ATAPI) disks have names like "sd0", "sd1", etc. ATA/IDE drives have names like "hd0"; and floppy disks have names like "fd0". Disk devices may also have more than one HFS(+) partition; the first HFS(+) partition of "sd0" is "sd0_hfs_a", the second is "sd0_hfs_b", etc. Disks without partition maps (such as floppies and ISO9660 CD-ROMs) are treated as though they consisted of a single HFS(+) partition, comprising the whole disk (e.g., "sd0_hfs_a").


MacOS.app supports mounting HFS(+) volume(s) which are already mounted by Mac OS X Server. This mode of access is called Shared mode because all the files and folders on Shared volumes are simultaneously accessible from Mac OS applications running inside MacOS.app and Mac OS X Server applications running outside of it. Shared mode was chosen as the default file system access mode because it does not require the user to unmount a volume from one environment before mounting it in the other.

Although Shared mode access provides the highest level of interoperability between Mac OS and Mac OS X Server applications, it is not compatible with Mac OS applications that require low-level disk access. Mac OS productivity applications are not affected by this incompatibility since they access files and folders via the high-level interface provided by the File Manager. On the other hand, disk utility programs typically require low-level disk access. Examples of disk utilities that require Exclusive mode access are Disk First Aid, and Norton Disk Doctor. Examples of disk utilities that require SCSI mode access are Drive Setup, and FWB's Hard Disk Toolkit. None of these utilities will function correctly on a volume accessed in Shared mode.

Volumes accessed via Shared mode are slightly less compatible with Mac OS applications than if they were mounted in Exclusive or SCSI mode. But they are far more flexible because they allow you to concurrently share data between Mac OS applications running inside MacOS.app and Mac OS X Server applications running in the Mac OS X Server environment. This means that the files and folders you see in MacOS.app can also be seen from Mac OS X Server.

In Shared mode you should be able to run nearly all of the applications you run on a native Mac OS system. One small difference between volumes accessed via Shared mode is that the size of the underlying "disk" may not be reported accurately. For small HFS disks (like floppies), it might be overestimated by a few kilobytes and for large HFS+ disks (like multi-gigabyte hard drives) it might be underestimated by a few megabytes. This cosmetic difference should not have any adverse affect, since block-level access is not permitted on disks accessed via Shared mode.

In general, other incompatibilities and inconsistencies result from conflicts over shared resources. For example, if a Mac OS application running inside MacOS.app is accessing a file (or group of files) at the same time that a Mac OS X Server application is accessing them, there is a risk that they might make conflicting changes.

One place where this arises is in the process by which the Mac OS Finder rebuilds the Desktop Database. In Mac OS X Server, the Desktop Database is a shared resource that is managed by an independent server task (the "DesktopDB" server) and which fields requests from various clients, including MacOS.app. This works well and provides a centralized place for serializing access to the shared Desktop Database files. However the mechanism used by the Mac OS Finder for rebuilding the Desktop Database conflicts with the Desktop Database server. Consequently, rebuilding the Desktop Database on a Shared volume will not always have the desired effect. This issue will be addressed in a future Finder and MacOS.app. As a workaround you can switch the disk to Exclusive mode, rebuild the Desktop Database, and then switch the disk back to Shared mode. See the section on the "Blue Volume Mount Options" control panel for information on switching modes.

Another example of a shared resource conflict can be seen when attempting to eject a disk from one environment (the Workspace or the Finder) while it is in use by an application in the other environment. In this case, the ejection attempt may appear to succeed (i.e., the volume's icon may disappear from the desktop) but the disk might not be physically ejected from the disk drive. If this happens, the solution is to switch to the other environment and eject the disk from that environment as well (after closing any files that may be in use first, of course). Since Mac OS X Server cannot tell if individual files are open by Mac OS applications running inside MacOS.app, the Workspace will refuse to eject a disk that is mounted in MacOS.app, even if there are no individual files opened from that volume by Mac OS applications. Going in the other direction is a little better; when you attempt to eject a removable disk from MacOS.app it will ask the Workspace to unmount any volumes mounted from that disk and to eject the disk. If there are no files open from that volume and no processes whose current working directory is set to a directory on that volume, then the disk will be automatically unmounted from Workspace and ejected - there will be no need to switch to the Workspace and eject the disk again.

Remember, having a Mac OS X Server application with its "current working directory" set to a folder on a disk marks that disk as "in use" the same way that having an open file does. For example, if you insert a floppy in the Workspace then in a Terminal window "cd" to some directory within the floppy, you will not be able to eject that floppy via MacOS.app.

Removable disks accessed via Shared mode are not ejected upon shutdown of MacOS.app (floppies are an exception).

How does Shared volume support work? MacOS.app contains the same File Manager code used by the native Mac OS with the addition of some logic that determines when a file system request is targeting an object on a Shared volume. These requests are passed over to the HFS(+) implementation in Mac OS X Server. The important thing to note is that this processing happens at the level of Mac OS File Manager requests, as opposed to disk driver requests or SCSI Manager requests. Thus, when you ask to "open" a file on a Shared volume, that request is sent to Mac OS X Server and is processed there. The results of the "open" in Mac OS X Server are passed back to MacOS.app and mapped into Mac OS "open" results. Then, a "read" from the newly opened file would be mapped into a Mac OS X Server "read" request and the results mapped in a Mac OS "read" result. The MacOS.app implementation of the Shared file system tries to map the file system requests and their results as closely as possible to native Mac OS. Applications should never know (or care) that they are running in the MacOS.app on a Shared volume, as long as they limit themselves to making File Manager requests and do not attempt to make disk driver or SCSI Manager requests.

The choice between Shared and Exclusive mode access can be made on a per-partition basis for disks with multiple HFS(+) partitions.


MacOS.app supports mounting HFS(+) disk volumes in a mode that permits block-level access. This mode permits certain disk utilities (such as Disk First Aid and some operations in Disk Copy) to run that would not work with a disk accessed via Shared mode. This is called Exclusive mode because disks accessed by MacOS.app in this mode appear exclusively in MacOS.app and cannot be accessed by Mac OS X Server applications. You can request that a disk or partition be accessed via Exclusive mode by using the "Blue Volume Mount Options" control panel.

When Mac OS X Server first detects an HFS(+) disk partition (either when starting up or when a removable disk is inserted into a drive) it mounts it and notifies MacOS.app. MacOS.app is also notified about disks that are not recognized or mounted by Mac OS X Server. When MacOS.app notices a disk that has been mounted in Mac OS X Server for which the user has selected Exclusive mode, it asks Mac OS X Server to unmount the disk and then mounts it exclusively.

Because it remains under the control of the Mac OS X Server SCSI drivers, a disk accessed via Exclusive mode cannot be accessed via the Mac OS SCSI Manager, even if the underlying disk is a SCSI disk.

Volumes accessed in Exclusive mode can be read from and written to, regardless of the access rights of the user.

Disk image files like the supplied StartupDisk.img are always accessed via Exclusive mode.

The choice between Exclusive and Shared mode access can be made on a per-partition basis for disks with multiple HFS(+) partitions.

Removable disks accessed via Exclusive mode are usually ejected upon Shutdown or Restart of MacOS.app. CD-ROMs are an exception and are not ejected upon shutdown, in order to more closely mimic the behavior of Mac OS.


MacOS.app supports SCSI disk devices that are recognized by Mac OS X Server. MacOS.app provides a special compatibility mode for accessing these devices via the SCSI Manager, just as they would be accessed under the native Mac OS. This mode provides the highest level of compatibility with Mac OS disk utilities, especially with those that require SCSI access, like Drive Setup.

Like Exclusive mode, SCSI mode must be selected by using the "Blue Volume Mount Options" control panel. When MacOS.app first detects a disk for which SCSI mode has been selected, it attempts to unmount it from Mac OS X Server. If this succeeds, MacOS.app can access it in SCSI mode without fear of interference from Mac OS X Server applications.

Volumes accessed in SCSI mode can be read from and written to, regardless of the access rights of the user.

Unlike the choice between Shared and Exclusive mode access - which can be made on a per-partition basis for disks with multiple HFS(+) partitions - accessing a disk via SCSI mode precludes any other sort of access, either by Mac OS X Server or via Shared or Exclusive mode in MacOS.app. One consequence of this is that a disk containing a UFS file system partition that is mounted by Mac OS X Server cannot be accessed via SCSI mode in MacOS.app. For example, if your system has only one hard drive and has separate partitions for UFS and HFS(+) file systems, you will not be able to access the disk in SCSI mode.

Removable SCSI drives without media present will become reserved for SCSI mode access if probed via a SCSI disk utility like Drive Setup.

SCSI mode access is not available for ATAPI devices (which includes the internal CD-ROM and optional Zip drive on some Power Macintosh G3 models) or IDE/ATA devices (which include the internal disks on most non-Server Power Macintosh G3 models).


In the "Apple Extras" folder of the supplied StartupDisk.img is the control panel to set the desired access mode for disks and disk partitions. Disks can be accessed in one of three modes (Shared, Exclusive, or SCSI), although not all disks will permit access in SCSI mode. A disk cannot be accessed in SCSI mode if it is not a SCSI disk (e.g., floppies, ATA/IDE/ATAPI disks). Nor can it be accessed in SCSI mode if there is a UFS file system mount point active on the disk at the time the mode switch is attempted (either when the control panel is launched or when MacOS.app is starting up).

Launching the "Blue Volume Mount Options" control panel displays a single dialog which can be dismissed by quitting the control panel or closing the window. Any changes that are made are stored immediately upon quitting the control panel, although most changes do not take effect until MacOS.app is restarted.

The control panel lists all the disk drives and disk partitions that it finds on the system, together with three columns of radio buttons, named after the three possible modes of operation: SCSI, Exclusive, and Shared. If a radio button does not appear in one of the columns, it means that the corresponding mode is not available for that drive (e.g., SCSI mode for an ATAPI CD-ROM drive). Radio buttons are used to convey the fact that each drive or partition can only be accessed in one mode at a time. For a brief explanation of how Mac OS X Server names disk devices, see the beginning of the "Disk Access Modes" section. If a disk partition is already mounted in Shared or Exclusive mode, it will appear in the control panel under that name (e.g., "sd0_hfs_a"). If it is a removable drive with no disk present, it will appear under the name of the drive (e.g., "sd0"). Finally, if it is being accessed via SCSI mode, it will appear labeled with its SCSI Bus and device ID (e.g., "Bus 0, ID 0"). In each case, these labels should correspond closely to what you will find in the "Where" string displayed in the Finder's "Get Info" dialog for that volume.

The same disk may appear under different names at different times in the "Blue Volume Mount Options" control panel depending on whether there is a disk in the drive. For example, the internal ATAPI CD-ROM drive on a Power Macintosh G3 will appear as "ATA drive sd0" when there is no CD-ROM in the drive, but as "HFS partition sd0_hfs_a" when a CD-ROM is in the drive.

If a disk has multiple HFS(+) partitions, they can be accessed in Shared or Exclusive mode independently from one another. In other words, the choice between Shared and Exclusive mode can be made on a per-partition basis. Similarly, Mac OS X Server can mount a UFS partition from a disk containing one or more HFS(+) partitions, each of which may be accessed in Shared or Exclusive mode. SCSI mode is different, though, because it requires complete control of all requests going to the disk. Therefore, selecting SCSI mode for one partition on a disk causes all the partitions on the disk to be accessed via SCSI mode. If you try this, you will see that the settings of the radio buttons automatically reflect this constraint. Similarly, you cannot select SCSI mode for a disk containing a mounted UFS file system. If you do select SCSI disk mode for a disk that contains an unmounted UFS file system, your selection will be honored. You will not be able to mount that UFS file system in Mac OS X Server while MacOS.app is accessing the disk in SCSI mode.

For fixed, non-removable disks, changes made via the "Blue Volume Mount Options" control panel will not take effect until MacOS.app is restarted. Removable disks are an exception to this rule: if you change the access mode for a removable disk then it will be accessed in that mode the next time you insert a disk in the drive. Consequently, you can quickly change the access mode for a removable disk by changing the setting in the control panel (and quitting it), ejecting the disk, and reinserting it - all without needing to restart MacOS.app.

There is one situation in which switching modes requires special care. When switching a non-removable disk to Shared mode from some other mode, you must shut down MacOS.app and wait for the Workspace to remount the disk on its desktop before re-launching MacOS.app. Otherwise, if you were to switch a disk to Shared mode and restart MacOS.app (e.g., from the Finder) then the Workspace might not have enough time to remount the disk before MacOS.app claimed it in Exclusive mode again. In this situation, the disk would not appear on the desktop of the Workspace and the "Where" string in the Finder's "Get Info" dialog for the disk would indicate "Exclusive". If this happens, the only way to get the Workspace to remount the disk for Shared access is to log out of the Workspace (after shutting down MacOS.app) and log back in again.

Currently, settings made via the "Blue Volume Mount Options" control panel are stored in the user's defaults database, although this might change in the future. Consequently, in a NetInfo environment, the same settings will be used for a user regardless of the machine they login to - beware. To see which disks have been set up in Exclusive mode, execute this command from the command line (i.e., in a Terminal window): "defaults read MacOS ExclusiveDisks". This "defaults" setting is a list consisting of device and/or individual partition names, separated by spaces. To see which disks have been set up in SCSI mode, execute this command at the command line: "defaults read MacOS SCSIDiskLoans". This list consists of ":" pairs, separated by spaces. If a disk or partition is not mentioned on either of these lists then MacOS.app will attempt to access it via Shared mode. In general, there should be no need to view these settings from the Mac OS X Server command line rather than with the "Blue Volume Mount Options" control panel. However, this information is provided because it might be useful for remote diagnosis and trouble-shooting.

The disk mode selections made via the "Blue Volume Mount Options" control panel are only requests. In some cases, it might not be possible to honor them and MacOS.app may mount a disk in a mode other than the one selected in the control panel. To find out what mode a volume is being accessed in, you can interpret the "Where" string displayed in the Finder's "Get Info" dialog for that volume, as described at the beginning of the "Disk Access Modes" section. For example, if Exclusive mode is selected for a disk partition but a Mac OS X Server application has a file from that partition open, then MacOS.app will not be able to get Exclusive access when it starts up. Rather than having the disk not appear in MacOS.app in this situation, MacOS.app will fall back to mounting the disk in Shared mode.


There is a preference setting, "Disk Mounting", which can restrict MacOS.app's ability to unmount volumes from Mac OS X Server. In turn, this can prevent MacOS.app from ejecting removable disks and from accessing disks via Exclusive or SCSI mode.

To invoke the "Disk Mounting" preference panel, select it in the "Computer Settings" submenu of the Mac OS X Server Apple Menu. The panel includes some explanatory text. To change the panel's setting, you must be logged-in as root. Changes will not take effect until Mac OS X Server is restarted.

The default setting for a Server configuration is either "Fixed & removable disks" or "Only fixed disks". In a non-Server configuration where MacOS.app is going to be used extensively, it may be more convenient to select the "Only the startup disk" setting, for reasons that will be explained. However, this setting is not appropriate for a Server, because it means that files cannot be served from disks other than the startup disk unless someone is logged into the server. The other two settings are more appropriate for a Server because they permit files to be served from all disks attached at startup time, regardless of whether anyone is logged into the server.

In either of the Server modes you must be logged-in as root if you wish to use MacOS.app to eject removable disks or access disks via Exclusive or SCSI mode. This is a security precaution that is appropriate for a Server configuration, but might be overly restrictive for a Macintosh that is being used as a personal workstation, especially if it is shared between non-root users. If you select the "Only the startup disk" setting in the "Disk Mounting" preference panel (and restart Mac OS X Server), then disks other than the startup disk will be mounted upon login and unmount upon logout. As a result, the user that logs in will be able to use MacOS.app to unmount these disks, e.g. in order to eject a removable disk or to access a disk via Exclusive or SCSI mode.

Disk Drive Support

The following sections discuss the level of support provided for various kinds of disk media. Since some things apply to whole families of drives (e.g., SCSI drives) and some things apply to specific kinds of drives (e.g., CD-ROM drives), there is some overlap between the categories and you may need to read them all in order to find what you are looking for.


SCSI disk drives can be accessed in Shared, Exclusive, or SCSI mode.

For more information on SCSI mode file system access, see the section on "SCSI Mode File System Access". For more information on switching the access mode, see the section on the "Blue Volume Mount Options" control panel.

SCSI disk devices (e.g., hard drives, CD-ROM drives, Zip drives, and Jaz drives) are supported, including those with multiple partitions. In Shared and Exclusive mode they behave like generic SCSI hard drives with the addition that disk-insertion detection and auto-ejection are supported. In Shared and Exclusive mode, special vendor-specific drivers (e.g., the Iomega Driver) are not loaded or used. If the drive has a manual-ejection button then it will be disabled while the disk is being accessed.

In SCSI mode, most third-party SCSI drivers are supported, including those that make possible special device-specific features (e.g., hardware write-protection or password protection). In this mode, MacOS.app supports the original SCSI Manager and SCSI Manager 4.3 with limitations. See the section on "Bugs and Compatibility Issues" for more details.

Mac OS X Server implements SCSI device arbitration. This means that only one client can send SCSI commands to a SCSI device at a time. Often, in the case of SCSI disks, this client is the Mac OS X Server file system. When MacOS.app is accessing a disk partition in Exclusive mode, then it is the client. For the purpose of SCSI mode access, MacOS.app can "see" any SCSI device not in use by Mac OS X Server (or any other client). In particular, removable disk drives with no media in place are always visible to MacOS.app and if probed will be accessed in SCSI mode until MacOS.app is shut down.


ATA/IDE/ATAPI drives can be accessed via Shared or Exclusive mode. They cannot be accessed via SCSI mode.

"ATA" and "IDE" are used interchangeably. The internal hard drives on most non-Server Power Macintosh G3 models are ATA/IDE drives. MacOS.app does not currently support the Mac OS ATA Manager. A future release may include an "ATA mode" similar to the existing "SCSI mode". "ATAPI" drives are special ATA/IDE drives with additional features. The internal CD-ROM and optional Zip drives on Power Macintosh G3 models are ATAPI drives.


Floppy drives can be accessed in Shared or Exclusive mode. They cannot be accessed in SCSI mode.

High Density (1.44 MB) floppies are fully supported. 800 KB floppies are supported read-only.

MacOS.app supports auto-detection and auto-ejection of floppies. Low-level initialization is only supported in Exclusive mode. If you insert a floppy that lacks a low-level format, it will be automatically accessed in Exclusive mode in order to permit you to initialize it. If, after initializing such a floppy, you wish to access it in Shared mode, you will need to eject it and reinsert it. See the section on the "Blue Volume Mount Options" control panel for instructions on how to change the mode. See the "Bugs and Compatibility Issues" section for other floppy issues.


Disk image files are volume images in Mac OS Disk Copy uncompressed format, stored in Mac OS X Server's UFS file system. They are always accessed in Exclusive mode. From the Mac OS X Server environment, they appear as large binary files whose name end in ".img". In the Mac OS environment, however, they appear as regular Mac OS volumes (with a special icon). By default, MacOS.app will startup from the disk image file in /Local/Library/MacOS/Users//StartupDisk.img. See the section "Working With Disk Image Files", below, for details.
CD-ROMs are supported in MacOS.app. They behave like locked SCSI hard drives when accessed via Shared or Exclusive mode. MacOS.app supports auto-detection and auto-ejection of CD-ROMs.

HFS(+) CDs can be accessed in Shared, Exclusive, or SCSI mode. DOS, ProDOS, PhotoCD, ISO 9660, and High Sierra CDs are automatically mounted in Exclusive mode, even if Shared mode is selected. They are also accessible in SCSI mode.

ISO9660 CDs are treated specially: they are mounted simultaneously in Mac OS X Server and in MacOS.app, but they are mounted in Exclusive mode in both environments. This may sound like a contradiction, but is possible because CD-ROMs are read-only media and there is no risk of writing inconsistent data or causing disk corruption. ISO9660 CD-ROMs are the only exception to the rule that disks appearing in MacOS.app in Exclusive mode do not appear in Mac OS X Server.

Only the first session of a multisession CD-ROM will be accessible in Shared or Exclusive mode. To access additional sessions the CD-ROM drive must be accessed in SCSI mode. See the section on the "Blue Volume Mount Options" control panel for instructions on how to change the mode.

Audio CDs are only accessible in SCSI mode. Audio playthrough is not supported, however.

If an Audio CD or any other CD in an unsupported format is inserted in Shared or Exclusive mode then the CD will automatically be ejected from the drive.

CD-ROMs are not ejected upon Shutdown or Restart of MacOS.app, even if accessed via Exclusive mode. This mimics the behavior of the native Mac OS.


DVD ROM disks are supported in Exclusive and SCSI modes. MacOS.app supports the UDF file system format that is used on these disks. DVD ROM movie playback is not supported in Mac OS X Server.

Working with Disk Image Files

Use of Disk Image Files

Although disk image files are used as default startup volumes in this release, they may not be the best choice for long-term use. More convenient startup volume options are available in this release which supports HFS(+) volumes that can be shared between Mac OS X Server and Mac OS.

You can use the Mac OS Startup Disk control panel to select a different startup volume. This can be very useful, but a few important steps are needed to properly setup a startup volume. If you plan to use this feature, be sure to read the "Startup Options" section below.

The StartupDisk.img created when you first launch MacOS.app is a relatively small startup volume (175 MB), which will not allow installing much software. It is suggested that you use available Mac OS partitions or create additional disk images to hold Mac OS applications and documents.

Even if you install applications elsewhere, as suggested, many applications also take up space in the System Folder on the startup disk. Enough free space (about 40 MB) has been left for the System Folder additions of a few applications. However, you may eventually run out and be forced to enlarge your StartupDisk.img, as described below, or switch to startup from an HFS(+) partition.


At startup time, after finding the startup volume (StartupDisk.img by default), MacOS.app will search for and attempt to mount image files (files ending in ".img", but excluding StartupDisk.img) in the following Mac OS X Server directories:
Note that the first two directories are private to a particular user ("~" means the current user's home directory), whereas the last two are global to all users of the machine.

MacOS.app respects the file permissions for disk images. If the user has only read permissions for the disk image file in the Mac OS X Server file system, then the image will appear locked in MacOS.app.

You can create new disk image files in Mac OS X Server by using Disk Copy in MacOS.app and creating the disk image on a shared volume, which can then be moved to one of the above directories. You can also create a disk image on a native Mac OS system and transfer the file to Mac OS X Server with "ftp" (or other utility).

Alternatively, you can use the provided "createimage" tool in the /usr/bin/ directory. It creates an empty image file that can be made available within MacOS.app. To use this tool, from a Terminal window (when logged in as the user who intends to use the image), execute:


where "num" is the desired disk image size in MB and "name" is the pathname of the image file to be created, usually of the form:
For example:
The next time MacOS.app is started, Mac OS will present a dialog offering to initialize this new volume; you should allow the initialization to proceed.
At the present time there is an issue that prevents MacOS.app from initializing the disk image file created by the createimage tool. A future release of MacOS.app or the createimage tool will correct this issue, but until they become available you should not use createimage to create new disk image files for use with MacOS.app, and should instead use one of the other methods for creating new disk image files described earlier.
You can enlarge your StartupDisk.img by creating a new disk image with "createimage," and copying the contents of the startup disk to that new image. Perform the following steps to create a larger startup disk. MacOS.app will now startup from your newly created startup disk.

When you are satisfied that the new startup disk image is OK, the old image may be removed to conserve disk space.

It is also possible to transfer image files to native Mac OS and modify their contents using Apple's Disk Copy utility. The correct file type and creator for image files are 'hdrv' and 'ddsk', respectively. These can be set when transferring if using Fetch, or afterwards via ResEdit or other utilities. The version of Disk Copy included with this release of MacOS.app supports opening disk image files with incorrect file types via drag and drop. Disk Copy will treat the data fork as a valid image only if the resource fork does not have any of the NDIF specific resources in it (or if there is no resource fork at all). So, if ftp is used to download just the data fork of a Disk Copy image file, Disk Copy should be able to mount it.

Startup Options


By default, MacOS.app starts up from your StartupDisk.img. If you have issues with your StartupDisk.img, see the section "Startup Disk Issues", below. If the currently selected Startup volume for MacOS.app does not support MacOS.app, a new StartupDisk.img will be created to allow proper startup.

If you wish, you may select an HFS(+) partition as your startup disk, using the Startup Disk control panel. You can even dual boot native Mac OS and MacOS.app from the same startup disk.

As with native Mac OS systems, you can hold the "C" key down to start up from the CD-ROM drive. This is done just after starting up MacOS.app, but before the gray screen appears.


Beginning with Mac OS 8.5 no special setup is required; you just run the installer. For Mac OS 8.5, installation will require that the target disk is in Exclusive (or SCSI) mode during installation. In future versions of Mac OS it will be possible to perform an installation to a target disk in Shared mode as well.

Once your new startup disk is set up, select it using the Startup Disk control panel and then restart MacOS.app.

After setting your system to start up from a Mac OS partition, you may remove the StartupDisk.img file from the /Local/Library/MacOS/Users/ directory.


If MacOS.app immediately quits on a user's first attempt to start up, check the ownership of the /Local/Library/MacOS/Users/ directory. If it is owned by root, change the ownership to using the chown command, then restart MacOS.app.
If you have an issue with your StartupDisk.img, MacOS.app can be forced to install a new StartupDisk.img. When starting MacOS.app, hold down the Command-Option-Shift keys. You will be given the option to modify your PRAM file. You must modify your PRAM file to proceed with fixing your startup disk issues. If you accidentally pressed the Command-Option-Shift keys, you should choose the Quit option.

After modifying your PRAM file, you will be given the option of deleting, using or renaming your current StartupDisk.img. If the disk image is corrupted and you don't want to mount it, but you don't want to delete it, be sure to remove the ".img" extension when renaming. Renaming a disk image across Mac OS X Server file system volumes (mount points) will result in a copy (rather than a rename). This will take a while.

If the "Copying StartupDisk.img" dialog is cancelled when MacOS.app is not in the foreground (i.e., the dialog is frontmost, but is not active), the "Cancel" button may appear pressed, but then doesn't release. Click anywhere in the dialog to complete the cancel operation.

Renaming a startup disk image across file system volumes when there is insufficient disk space available may cause Mac OS X Server to fail. Due to the large size of the disk images, caution should be used when maintaining several on your disks.


If you receive the "Helper Copy Prolem. Exception raised during the write." alert while copying the StartupDisk.img, verify that there is sufficient disk space available for the copy (~ 175 M). This alert can be received if there is negative space available as reported by "df". As a non-root user, type "df -kl" in a Terminal window to get this information.

Bugs and Compatibility Issues


If you use the Mac OS X Server Workspace process menu to force-kill MacOS.app, an issue occurs if MacOS.app has gone through a restart since being launched by the Workspace. The issue occurs because whenever MacOS.app goes through a restart it gets different process IDs for all of the processes associated with MacOS.app. The force-kill option will shut down all of the MacOS.app windows, but the MacOS.app processes will not be killed because the kill signal will be sent to the original process IDs which no longer correspond to the running MacOS.app processes. Therefore, it will appear that MacOS.app has been killed, but you will not be able to launch a new MacOS.app. To work around this issue, you must manually kill the old MacOS.app processes from the command line using the kill command. You must first find the process ID of MacOS.app. You can do this by typing the following command from the command line:
This will produce output that looks something like this:
This output shows that the process ID for MacOS.app is 721 and the process ID for the grep command you just ran is 752. You must now kill the MacOS.app process by entering the following command (substitute the process ID of the MacOS.app process you are trying to kill for the process ID 721 as shown below):
After killing the MacOS.app process in this way, you should be able to launch a new MacOS.app from the Workspace.
The Mac OS Applications window that appears when the Applications menu is "torn off" does not list any Mac OS X Server applications that normally appear in the MacOS.app Applications menu. To switch from MacOS.app to another Mac OS X Server application, you must use the Applications menu and not the tear-off window.
When running MacOS.app using the presently shipping version of Mac OS (System 8.5.1), there is an issue that may cause loss of connection to AppleShare File Servers that are connected via TCP/IP. The workaround for this issue is to connect to the server using the AppleTalk protocol instead. To do this, when selecting the File Server using the Chooser, hold down the Option key when you click on the OK button. This forces the system to connect via AppleTalk and not TCP/IP. This issue will be corrected in a future version of Mac OS.
The present version of Mac OS X Server is unable to read PC Zip disks that have been formatted using the Iomega Tools. The issue does not occur if you initialize the Zip disk using MacOS.app by accessing the Zip drive using Exclusive mode and then initializing it by selecting the Finder's "Erase Disk" menu item.
When running MacOS.app using the presently shipping version of Mac OS (System 8.5.1), Norton's CrashGuard INIT will not work in MacOS.app. A future version of Mac OS is expected to correct this issue.
There is an issue that occasionally occurs when launching PowerPC Macintosh applications from disks accessed via direct SCSI mode. The issue causes MacOS.app to hang because of repeated timeouts attempting to access the disk. If you encounter this issue try changing the disk access to Exclusive mode. See the "Disk Access Modes" section for more details.
When running MacOS.app using the presently shipping version of Mac OS (System 8.5.1), Symantec's ACT! will not run properly in MacOS.app. The issue is due to a known incompatibility between MacOS.app and Mac OS 8.5.1 or earlier with regard to the GetSpecificHighLevelEvent() Toolbox call. An application that calls GetSpecificHighLevelEvent() directly will crash and possibly crash MacOS.app as well. A future version of Mac OS is expected to correct this issue.
When running this version of Eudora Pro on MacOS.app, the application crashes because it is making a power manager call which is not implemented in MacOS.app. A future version of Eudora Pro will correct this issue.
When running the MacBench 5.0 "all" test (with CD in), MacOS.app will crash when it arrives at the Microsoft Word formatting stage. This issue is currently under investigation and should be corrected in a future version of MacOS.app.
When launching Myth II under MacOS.app you may receive an error dialog saying "Myth does not have enough free memory to launch. Try closing open applications or turning on VM". This message is incorrect; the actual issue is due to the Myth application attempting to perform a dynamic screen resolution change that is not supported in MacOS.app. In order to run Myth II under MacOS.app you must first change the screen resolution in Mac OS X Server to 640x480 using the Preferences.app application, then launch MacOS.app with the new screen resolution and Myth II will run correctly.
Switching from MacOS.app to Mac OS X Server using command-return is not allowed during startup of MacOS.app. Attempts to do so prior to the Finder starting up will be ignored.
MacOS.app runs the MacOS in a multiuser environment. Native MacOS runs in a single user environment. In the Mac OS X Server environment a user must be the owner of a file in order to unlock it. If you try to move a locked file or delete a locked file, owned by someone else in the underlying file system, you will get an "access privileges" error. You can workaround this limitation in several ways. 1) use the chown command to change the owner of the file 2) shutdown MacOS.app and login to the system as the owner of the file, then start up MacOS.app again 3) do the move/rename in a terminal window as root or after doing a su to the owner of the file.
Disks formatted with 3rd party utilities and utilizing 3rd party drivers may appear on the desktop with a different icon than they would under the native Mac OS. For example, a removable Zip or Jaz disk may appear on the desktop as a generic hard drive icon.
The Mac OS 8.5 installer will not function correctly when attempting to install Mac OS 8.5 onto a disk volume that is being accessed via Shared mode. This issue will be resolved in a future Mac OS release. If you need to install Mac OS 8.5 from within MacOS.app, switch the access mode of the target disk volume to Exclusive mode. See the "Disk Access Modes" section for more information.

Versions of Disk First Aid and the Mac OS installer currently shipping will not function correctly when their target is a disk accessed via Shared mode. Starting in a future version of Mac OS, Disk First Aid will simply report "no errors" for disks accessed via Shared mode without actually examining the disk. You can run the Mac OS X Server version of Disk First Aid (DiskFirstAid.app) or you can set the access mode of the target disk to Exclusive mode. See the "Disk Access Modes" section for more information.

In general, the Drive Setup application cannot be used on disk volumes that are accessed via Shared or Exclusive mode. It can only be used on SCSI disks (not ATA/IDE/ATAPI disks) that are accessed via SCSI mode. One of the things that the Mac OS installer does is ask Drive Setup to update the disk drivers of all the disks connected to your Macintosh. Disks that are being accessed via Shared or Exclusive mode will not be detected by Drive Setup and so will not have their drivers updated. Therefore, if you ever intend to boot your Macintosh into the native Mac OS, you should run Drive Setup manually from within the native Mac OS and select the "Update Drivers" menu option. Setting your disks to be accessed via SCSI mode from within MacOS.app might also work, but there are a few things that might prevent this from working as well as it would if you did it from within the native Mac OS: you might have non-SCSI disks on your system, or you might not be able to get SCSI mode access to all of your disks since at least one of them is used as the Mac OS X Server boot disk and therefore cannot be unmounted. See the "Disk Access Modes" section for more details.

If you have a 36 GB disk, do not format it with the version of Drive Setup that is located on your MacOS.app Startup disk. This could result in an improper format of the disk. Drive Setup 1.7.1, which can be found on the Mac OS X Server installation CD, should be used to format 36 GB disks.


Desktop rebuilds on some volumes mounted in shared mode may take longer than the same rebuilds in native MacOS. It is recommended that if you must rebuild your DesktopDB, you do it in native MacOS or in MacOS.app using Exclusive mode. In fact, a rebuild of the DesktopDB in shared mode does not actually delete the old DesktopDB files (although it appears from the progress dialog that it does), so repair of any damaged entries may not be as complete as would be the case in Exclusive mode or in Native Mac OS.
There is an issue that only happens when running with Mac OS System 8.5 or 8.5.1, in which MacOS.app crashes on startup after being improperly shut down. This is a side effect of putting up the "Your Macintosh was improperly shut down" dialog and will be fixed in a future release of Mac OS. The workaround to this issue is to uncheck the "Shut Down Warning" checkbox in the General Controls control panel. Note that if you do this, not only will there no longer be a warning dialog after crashes, but Disk First Aid will not be automatically run in such cases. You should run Disk First Aid to check the integrity of your file system after all improper shutdowns. There is a Mac OS X Server version of Disk First Aid (DiskFirstAid.app) that can be run on volumes shared with Mac OS X Server. In order for Disk First Aid in MacOS.app to run on a volume, it must be mounted in "Exclusive" mode (see the Disk Access Modes section). Or you can boot into native Mac OS and run Disk First Aid on the volume in question.
The runtime performance of MacOS.app is sensitive to other processes running on the Mac OS X Server, especially if these other processes consume the majority of "CPU" time. These types of processes are known as "CPU-bound" or "CPU-intensive" processes. The runtime performance of MacOS.app is highest when these types of processes are not running in Mac OS X Server.
In this release, Shared disk mode may be slower than other modes for some operations. If this is a concern, consider switching disk access modes or using disk images (which are always accessed in Exclusive mode). Disk access modes are discussed in detail in the "Disk Access Modes" section. Shared mode performance is expected to improve significantly in future releases.
On native Mac OS, using Command-Power to generate a NMI invokes the installed debugger (MacsBug) or invokes MicroBug if no debugger is installed. MicroBug is not currently supported in MacOS.app, so Command-Power with no debugger installed is ignored. When a debugger is installed, you may occasionally have to use Command-Power more than once to invoke the debugger. A current version of MacsBug is provided in the Apple Extras folder. Older versions are not compatible.
When logging out of Mac OS X Server with MacOS.app running, MacOS.app will come to the foreground with a dialog informing the user of the steps to safely shut down MacOS.app. The Workspace logout will be stopped. Upon shut down of MacOS.app, the user will again have to select Logout from the Workspace File menu. If MacOS.app was started from a shell window, it is not registered with the Mac OS X Server, so it will simply be killed during the logout process. This is why we don't recommend starting MacOS.app this way. Also note that if MacOS.app has gone through a restart since being launched by the Workspace, the process IDs for MacOS.app will have changed and the Workspace will not be able to contact it to initiate the safe shutdown dialog. This will also result in MacOS.app being killed during the logout process.
If Mac OS X Server runs out of disk space for virtual memory when MacOS.app is trying to allocate sparse virtual memory for an application, Mac OS will likely crash. This issue will be addressed in a future version of Mac OS X Server.
Mac OS has a limitation that sometimes causes aliases created on removable disks to fail when they are taken to a machine other than the one on which they were created. Because running MacOS.app is much like taking your disks created under native Mac OS and moving them to a different machine, this bug may manifest itself even though you did not physically move your disks to a different machine. This issue will be addressed in a future version of Mac OS.
Starting with Disk Copy version 6.3.3, it is possible to mount Disk Copy disk images from a Shared volume. However, it is not possible to create a disk image from an existing disk which is being accessed via Shared mode (i.e., using either of the "Create Image from Folder..." or "Create Image from Disk..." items in the "Image" menu of Disk Copy). If you are using an older version of Disk Copy to mount a disk image, or you are trying to create a disk image file from an existing disk, you will need to set that disk volume to be accessed via Exclusive mode. See the "Disk Access Modes" section for more information.

Disk images will only mount from shared volumes when the new Disk Copy driver (6.3.3) is loaded. This will happen if you run Disk Copy 6.3.3. The newer driver will override older drivers and "stick" until Shutdown once loaded. This does mean that if you mount an SMI (Self Mounting Archive) created with an earlier version of Disk Copy before the new Driver has loaded, it will not work. The workaround is to run Disk Copy 6.3.3 once.


There are two kinds of "Disk Initialization": low-level formatting is device-specific and only need to be performed once for the life of the device, whereas high-level formatting simply writes an empty filesystem onto a device that already has a low-level format. The Finder's "Erase disk..." menu option usually only performs a high-level format, except for floppies, where it also causes a low-level format to be performed. The low-level formatting and partitioning of SCSI and ATA/IDE drives is performed by the Drive Setup application.

SCSI mode: The low-level formatting and partitioning of SCSI disks can only be achieved via Drive Setup for disks that are accessed via SCSI mode. Currently, this is not supported for ATA/IDE drives.

Exclusive mode: The Finder's "Erase disk..." menu option should function as expected for all volumes accessed via Exclusive mode. It will even perform a low-level format for floppies, as long as they are accessed via Exclusive mode.

Shared mode: Neither Drive Setup nor the Finder's "Erase disk..." menu option will function for disks accessed via Shared mode. You should not attempt to reformat or erase a volume that is being accessed via Shared mode. If you select a Shared disk and invoke the "Erase disk..." menu option and then select either the "Mac OS Standard" or "Mac OS Extended" format, then the operation will be aborted and you will get an error alert stating that the "Erasing the disk failed!", and the volume will be unmounted causing it to disappear from the desktop. If this happens, you can remount the volume via the Disk First Aid application - no data will be lost or altered.

The mouse cursor may freeze while performing the low-level format portion of the initialization process on a floppy. Switching to Mac OS X Server will be disabled until the formatting has completed, which may take several minutes.

MacOS.app ignores UFS disks by design, so you cannot reinitialize a UFS disk as HFS(+) with MacOS.app. However, you can do this via the native Mac OS.


Read-only disk images can be shared via NFS by instances of MacOS.app running on different machines, but read/write images must not be shared or image corruption will result. Note that startup disk images (StartupDisk.img) are always read/write. In the future these rules will be enforced by MacOS.app when NFS advisory locking (rpc.lockd) is available in Mac OS X Server; but for now don't try it. The sharing of all volume types works fine via Personal File Sharing and AppleShare.
Floppy drives have traditionally been treated specially in the Mac OS startup process; the Mac OS always looks for a bootable floppy before attempting to start up from the disk chosen via the Startup Disk control panel. Originally, this was done in order to make it possible to start up a Macintosh with a floppy in case of hard disk corruption. Consequently, the Mac OS attempts to eject any non-bootable floppy that it finds in the drive during startup. MacOS.app inherits this behavior, but, unlike the native Mac OS, can be prevented from doing so by Mac OS X Server applications that may have files open on the floppy, not allowing it to be ejected from the drive. If this happens, MacOS.app will be unable to start up. If you would like to share files from a floppy between Mac OS X Server applications and MacOS.app applications, you should insert the floppy after starting up MacOS.app. Alternatively, you could eject it before launching MacOS.app and reinsert it after MacOS.app has started up.
When inserted, HFS(+) disks may take longer to mount in the Finder if accessed in Exclusive mode rather than in Shared mode. The extra delay results from the fact that HFS(+) disks are automatically mounted by Mac OS X Server and then need to be unmounted on behalf of MacOS.app in preparation for being mounted in Exclusive mode. This extra step essentially doubles the time required to mount a disk and may be noticeable - especially with slow media like floppy disks.

A request to eject a removable disk within MacOS.app may fail silently if the disk is shared with Mac OS X Server and files are open on the Mac OS X Server side (or a process has its current working directory set to a directory on the disk). In this situation, MacOS.app will behave as though the disk had been ejected (e.g., the disk's icon will disappear from the Finder's desktop), but the disk will not have been physically ejected from the drive. In this situation, you will have to switch to Mac OS X Server and eject the disk via the Workspace (after closing any open files, of course).

MacOS.app ejects all removable media upon shutdown if they are accessed via Exclusive mode, with the exception of the CD-ROM drive. If you select a removable disk as the startup disk using the Startup Disk control panel and that disk is accessed via Exclusive mode, then you will have to quickly reinsert the disk into the drive during the restart.


The Mac OS X Server permissions model is enforced on volumes accessed in shared mode. The way permissions are enforced differs for HFS and HFS+ volumes, due to differences in their ability to store permission information. HFS volumes are unable to store permission information and therefore permissions have to be synthesized whenever they are needed. The permissions for the volume's mount point are used as the starting point for this synthesis (with appropriate differences for files versus folders). Moreover, when Mac OS X Server starts up, it mounts local volumes, setting the owner of these volumes to be root and the group to "macos". MacOS.app runs with an effective group id of "macos". By default, the macos group is set up to allow read/write access. Thus any user running MacOS.app will have access to all files and folders on HFS volumes mounted in shared mode.

HFS+ volumes mounted in shared mode behave similarly to HFS volumes with the exception of permissions that are explicitly set. Permissions are saved to disk on HFS+ volumes and are persistent on Mac OS X Server. However, native Mac OS completely ignores the permission information: it is neither enforced nor maintained. The HFS+ volume mount point will be owned by root and the group will be set to "macos", just as with HFS volumes. When a file is created the current user will be owner of the file and the group will be "macos". This will enable users in MacOS.app to access files as if they were running native MacOS. Please note that once permissions are set on HFS+ volumes they are honored when MacOS.app runs. So if you, or someone else, sets permissions in a terminal window, the above mechanism to allow MacOS.app access (via group macos) to files and folders will not allow access for someone without appropriate permissions to a file or folder. Unfortunately, MacOS was not designed to run in an environment where file access permissions might deny access. In most cases volumes mounted in shared mode will return "access denied" error codes that the Finder will pass along to the user when a permissions failure is noticed in the underlying file system. But there may be some cases where a confusing error may occur - so if you see strange error messages or odd behavior from an application on an HFS+ volume mounted in shared mode, keep permissions in mind.

As noted above, the group "macos" is a special group used to allow users of MacOS.app to access HFS and HFS+ file systems. If this group is removed or renamed, MacOS.app will not be able to access some local filesystems, and will refuse to run unless you are logged in as root.

Apple file services uses group permissions to control remote access to exported filesystems. If you set the group of an exported filesystem to anything other than "macos", then non-root users will not be able to access these filesystems in MacOS.app. To set the group for exported file systems using Remote Administration, click Disk & Share Points and click the disk or folder you want to share, then click Set Privileges.


The R1.1 version of Mac OS X Server supports UNIX symbolic links in the Workspace. However, MacOS.app does not understand symbolic links on volumes mounted in shared mode. When a symbolic link is seen by the Finder or any other application in MacOS.app, the underlying file system always resolves the link. This would be like always resolving a MacOS alias. This behavior is not normal in a MacOS environment, so you may run into unpredictable results if you try to use symbolic links on volumes that are accessed in shared mode. One symptom you may see is a folder that does not contain any items or fewer items than there should be. If you must use symbolic links on volumes accessed by MacOS.app in shared mode, you may want to place the links in a well known directory (a folder called "symlinks", for example). Alternatively, name the symbolic link so it appears at the end of directory when sorted by name (zMyLink, for example). This issue will be fixed in a future version of Mac OS X Server.
When MacOS.app starts up, it uses Mac OS X Server's sound preferences to initially set volume, balance, and mute levels. Changes to these preferences in MacOS.app will also change Mac OS X Server's preferences. While MacOS.app is running, changes to Mac OS X Server sound preferences will not change MacOS.app sound preferences.

Playing sound from an application running in Mac OS X Server at the same time an application is playing sound in MacOS.app may result in unpredictable results.

Sound input is not currently supported. This will affect speech recognition software.


Video capture is not currently supported.
Some applications that require special hardware support, such as the Apple Video Player, will not work correctly under the BlueBox. These applications fail during startup and incorrectly post dialogs suggesting they could work if extensions are added to the System Folder.
When starting up on the localized disk images available with MacOS.app, the default keyboard setting while running in Mac OS may differ from the keyboard setting in the Workspace. In Mac OS, this can be changed using the Keyboard control panel. Refer to the "Using different languages" section of Mac OS Help - available from the Help menu in the Finder.
Applications are advised to always use the Scrap Manager to access the Scrap. Direct scrap access may not behave correctly.

When copying data from MacOS.app to a Mac OS X Server application, it may take a noticeable period (up to several seconds) before the pasteboard is synchronized with data from the MacOS.app clipboard. If a paste is performed before this time (e.g., immediately after switching out of MacOS.app), the data may be incorrect, and the paste should be performed again.

MacOS.app supports the pasting of Japanese text between the Mac OS and Mac OS X Server environments. Starting with System 8.5.1, Japanese text can be copied to or from a Japanese localized Mac OS if MacOS.app was started with the Mac OS X Server Localization Preference set to Japanese.


Just as with any Mac OS system, when applications are installed, they sometimes install resources into the System Folder on the startup volume. If you later change the startup volume or System Folders, those applications which require resources located in the System Folder, may not work as desired. In order for these applications to run correctly, you must either run the installer or manually move the appropriate pieces to the startup volume System Folder.
Serial is not supported in this release of MacOS.app; applications attempting to open either port will receive a notInitErr (-900). A future release of MacOS.app will have serial support.
Because serial is not yet supported, attempting to print to a serial-attached printer will hang MacOS.app.
MacOS.app uses Mac OS X Server's cursor acceleration for its own, so use Mac OS X Server's mouse preferences to configure cursor acceleration for MacOS.app. The Mac OS Mouse control panel will have no affect on cursor acceleration.
Switching between Mac OS X Server and Mac OS can only happen at SystemTask() time. If Mac OS is hung, running a game which doesn't call SystemTask() or WaitNextEvent(), or sitting in MacsBug, you can't switch. You can still use Command-Shift-Q to force MacOS.app to quit. If this does not work, then the Mac OS X Server part of MacOS.app is hung and you will have to either telnet in from another machine and kill the MacOS.app process, or do a hard reboot of Mac OS X Server.

Similarly, if you switch to Mac OS X Server and then Mac OS hangs, you can't switch back. In that case, you must kill the MacOS.app process from Mac OS X Server. If MacOS.app drops into MacsBug while hidden, you may be able to unhide MacOS.app, but user input will not work. Command-Shift-Q should work.

The Video vertical retrace queue is hung off the System vertical retrace queue, and is therefore not synchronized with the actual monitor refresh interval.

If for any reason MacOS.app causes the Mac OS X Server cursor to go away, you can restore it with the following command from a Terminal window:


Multiple monitors are now supported. MacOS.app does not support display repositioning (via the Monitors control panel). If you try it anyway, you will have issues. To undo your changes, remove the "Display Preferences" file from the Preferences folder in the System Folder, and restart MacOS.app.

Some Mac OS applications that draw directly to the screen may continue to do so even after switching from Mac OS to Mac OS X Server. The occurrence of this behavior may be limited by switching to the Finder before switching to Mac OS X Server.

Video mirroring in Mac OS is the feature where both monitors of a dual-monitor system display the same exact picture. Use of this feature is not fully supported in MacOS.app. If you use video mirroring, make sure to turn it off before switching to Mac OS X Server from the application menu.

Hardware video acceleration is not yet supported.


Direct ADB access is not supported. Applications that read directly from ADB devices and expect mouse ADB events will not work.

Command-Shift-Q will force MacOS.app to quit. This only works if Mac OS is hung, not if the Mac OS X Server part of MacOS.app is hung. See more details under "Video", above.

MacOS.app will intercept the Command-Return key sequence and use it to jump to Mac OS X Server. This is the same key combination that PC compatibility cards use. However, some Mac OS applications (like MPW) need this key combination for full functionality. To disable special handling of this key combination, type "defaults write MacOS ScreenToggleKey 0" on the command line of a Terminal window.


To change the date, time, or time zone, use Mac OS X Server's Preferences.app, rather than the Mac OS Date & Time control panel. Changes to the date, time, or time zone using the Mac OS control panel will be ignored. Other features of this control panel, such as date and time formats and the menu bar clock, are fully supported.
If the "Copying StartupDisk.img" dialog is cancelled when MacOS.app is not in the foreground (i.e., the dialog is front most, but is not active), the "Cancel" button may appear pressed, but then doesn't release. Click anywhere in the dialog to complete the cancel operation.
MacOS.app does not support printing to the LaserWriter SC, or any other SCSI-based printer that requires the LaserWriter SC 7.0.1 driver.
The Mac OS Setup Assistant will allow the user to configure a local (serial) printer. If you do this and attempt to print to this printer, Mac OS will hang (see "Printing", above).

The Mac OS Setup Assistant on MacOS.app takes a little longer to configure printers than it does on native Mac OS. During this time do not select any menu or you will hang MacOS.app.

The Graphing Calculator has a bug which can cause a crash when running its "Mouse Control" demo and the application is located high in memory. This also happens on native Mac OS, but is much more common in MacOS.app.

The AppleCD Audio Player does not work in MacOS.app without additional configuration. Since the AppleCD Audio Player uses the SCSI Manager to find CD-ROM drives, this causes the application not to work in MacOS.app because CD-ROM drives are not mounted in SCSI mode by default in MacOS.app.

If the AppleCD Audio Player does not find at least one CD-ROM drive, it will return an error indicating that the CD-ROM drive is not responding. Some CD-ROM drives can be enabled to use direct SCSI access; see the section on the "Blue Volume Mount Options" control panel for instructions on how to switch the mode. If direct SCSI access is enabled on at least one CD-ROM drive, the AppleCD Audio Player will launch with no error and audio CDs can be played from MacOS.app, although audio playthrough is not supported.

Apple Video Player refuses to launch because MacOS.app does not currently support video capture.

When using the Extensions Manager, some of the installed Apple software is not a part of the "Mac OS 8.5 all" set (for example, "AppleScript" and "QuickTime"). This is normal when newer releases are installed.

Disk Copy prior to version 6.3.3 cannot mount images on a Mac OS volume that is in the Shared Access mode.

MacOS.app does not contain all the necessary Unicode converters to handle file and folder names on HFS+ volumes that were created on a native Mac OS machine using a system script other than Mac OS Roman. For example, if you take an HFS+ volume that was used on native Mac OS with the Japanese language kit installed, and you access it on Mac OS X Server, the file and folder names will appear garbled.


MacBench 4.0 crashes since it attempts to access hardware that is not supported by MacOS.app. MacBench 3.0 works correctly and MacBench 5.0 works with the exception of the issue noted previously in the paragraph entitled MacBench 5.0.

Networking modes promiscuous/raw are not supported in MacOS.app; therefore, applications such as Etherpeek are not supported.

Versions of CodeWarrior prior to the Pro 4 release do not support debugging; everything else seems to work. CodeWarrior Pro 4 (IDE 3.1) with version 1.3.6 of the MetroNub supports debugging and break/watch points.

RAM Doubler attempts to access the internals of Mac OS Virtual Memory and is therefore not compatible with MacOS.app.

Virtual PC attempts to access the internals of Mac OS Virtual Memory and is therefore not compatible with MacOS.app.

Disk Doubler Pro (and especially its Finder Menu feature) is not compatible with Mac OS 8.5 and therefore not with MacOS.app.

Speed Doubler causes MacOS.app to hang at startup, presumably because it attempts to modify undocumented Mac OS internals, and is therefore not compatible with MacOS.app.

The Disinfectant system extension (installed via the Protection menu of the Disinfectant application) should not be installed because it can cause some applications to quit with errors (such as Type 1 error). Conflict Catcher and Note Pad are particularly likely to crash when Disinfectant is present. Such errors are more likely to occur on MacOS.app than on native Mac OS because of the memory allocation scheme used in MacOS.app. Disinfectant is no longer supported by its developer, who recommends a full-featured virus protection program.

Adobe Persuasion 4.0's installer frequently fails with a bus error because of a bad memory access. Due to memory layout, this rarely occurs on native Mac OS, so a workaround is to run the installer there. Adobe has discontinued this product.

If drives formatted with FWB's Hard Disk Toolkit are mounted in "Shared" or "Exclusive" mode, any driver-level password protection will be ignored. Data that is encrypted will be inaccessible. Mounting these drives in "Direct SCSI" mode will re-enable password protection and access to encrypted data.

Descent II, like many other video games, uses SCSI Manager calls as part of its copy protection. By default, MacOS.app accesses SCSI disks via Shared mode. In both Shared and Exclusive mode, SCSI-level access is disallowed. The CD-ROM drive needs to be manually configured for direct access via SCSI mode. This can be done with the "Blue Volume Mount Options" application. However, the "Blue Volume Mount Options" application cannot set an ATA/IDE/ATAPI CD-ROM drive to direct SCSI mode. See the section on the "Blue Volume Mount Options" control panel for more information.

Published Date: Feb 18, 2012