From the MacWindows Archive:

Click for MacWindows home

Windows NT Services for Macintosh
Unsolved Mysteries

Updated December 27, 2001

(One more update on June 29, 2005)

Many of the bugs and problems listed on this page have no fixes that we know of. For some issues, readers have offered workarounds. And some issues listed here actually are solved.

Window NT SFM bugs and problems with known, repeatable solutions are reported on the MacWindows Server Tips page. (See also our Windows 2000 and Mac special report page.)

Know of a solution to one of these mysteries, or have a mystery of your own? Please tell as about it.

The problems listed on this page:

The jumping alias problem

DESCRIPTION: Mac aliases to directories on a Mac volume open the wrong directories, which seems to be a problem with NT's indexing. This bug was created by a 1998 Microsoft hotfix for Services for Mac that fixed the jumping icon problem, among others. (MacWindows reader Chris Lee says he's been building AppleScripts on each Mac to mount Win NT SFM directories.) Some reader experiences:

June 18, 1998
Darryl Lee

"When we do a Get Info on the aliases in question, say, 'Operations,' it says that it's pointing to: '*:NTMAC:Corporate.' Very strange. It happens to aliases that are created automatically (the Recent Servers folder in the Apple menu), as well as to aliases that were created manually."

July 8
Dave Dalton reported that the alias problem is causing Macs to hang when they mounted an NT server. He also found a workaround:

"The Apple Menu Options 'Remember recently used items' had a major conflict with the NT server running the most recent SFM hotfix. I am guessing that this is a result of the alias corruption problem. Turning off 'Remember recently used items' appears to have fixed the problem."

July 13, 1998
Tom Ackenhusen of the Fermi National Accelerator Laboratory told us of a work around he uses for the problem:

"Every time we reboot our NT server, we go into the Windows File Manager on the server and delete and recreate the Mac volume. Note that we don't delete or touch the NT directory or contents in this process. We just use the MacFile menu of File Manager to remove the Mac volume for the network folder and then recreate it. Since you can't remove the volume when users are connected, we often have to stop and restart SFM before doing this if users have connected."

Sept. 17, 1998
Dagfinn Andersen

We have also experienced the alias problems when installing the latest hotfix, but even worse: After a power failure the good old "files disappear from mounted server volumes on Macs"-problem hit us hard. When this happened earlier we were able to rescue our files by either redefine the Mac volume or moving folders around. But not this time. We even copied the files to another NT server (with the same hotfix) using different tools in Windows NT (scopy/File manager) but the files where still missing for our Macs.

To get back in business we installed the SFM-version prior to the hotfix....

We running NT on Digital Alpha hardware.

Sept. 23, 1998
Roger Menge wrote to say that Dave Dalton's suggestion above of turning off the Apple Menu Options 'Remember recently used items doesn't work for him. He doesn't use this feature, but has the problem of aliases mounting the wrong server volumes. It happens on everything from an LC II to the G3/266.

Oct. 13, 1998
Dan Schwartz

Dagfinn Andersen definitely needs to be using a U.P.S. with his Alpha server, along with configuring the UPS Control Panel (UPS Service).

Also, when he copied the files via XCOPY, not all of the NTFS streams may have made it across. This is guaranteed to corrupt fragile Resource forks. [This can also be an issue with restoring backups... I recommend UltraBac <> since it properly handles SFM volumes.]

Index rebuilding problem due to jumping icon hotfix

October 6, 1998 -- James Rupprecht reports that after installing the most recent NT Services for Macintosh hotfix, noticed some odd behavior:

"Now, whenever the server is restarted, the Mac volume is ALWAYS rebuilt on any volume that is more than about 1 gig in size. Smaller volumes are NEVER rebuilt unless there is a crash or a BSOD. This creates a couple of problems in that...

a. It takes a few minutes for those volumes to rebuild (during which time they are inaccessible); and
b. All of a user's icons are rearranged (important for those who use "large icon" view and like to arrange their files/folders).

I know the fix was supposed to cause NT to rebuild volumes after an abnormal shutdown, but it would seem that it is also causing rebuilds at other times as well."

Oct. 15, 1998.
A reader who runs a large Mac/NT Server site told us that he has been seeing a similar odd behavior:

"Regarding "Odd behavior with NT SFM Hotfix. October 6, 1998", this has been happening consistently on our large-Mac-volume NT servers from Day One. However, at least in our case, it is =not= a complete Mac volume rebuild that's's just a desktop database rebuild according to the Event Viewer ("The desktop database for volume "blahblahblah" can be loaded. Reconstructing the database."). But it =is= very annoying: one of our servers takes 1/2 hour to complete a normal reboot, if you include the rebuild. Our NT servers are supporting two Mac volumes (35G and 50G), both of which are supported by a Micronet DataDock 7000 RAID, level 5. Our RAID controller is completely hidden from the OS by a normal SCSI host controller, so that doesn't seem like a likely culprit to me. I think it's just an(other) SFM bug."

Oct. 9, 1998
Jon L. Gardner

Many of the Windows NT Server problems are directly related to the fact that NT maintains two separate directory indexes, one for the local system and Windows clients, and the other Services for Macintosh. Part of the overall instability with SFM is due to the fact that the SFM directory indexes get messed up easily and regularly. The "disappearing files" problem with SFM and NT 3.51, misbehaving folder windows, and probably even the Illustrator file problems are all related.

Whenever I run into any problem with SFM that looks remotely directory index-related, the first thing I do--preferably from the NT server console--is disconnect the Macs (or shut down SFM), move the offending Macintosh volume's folder into another folder, and then move it back to its original location. This forces SFM to rebuild the directory index, and often will fix the problem. Microsoft has posted several funky variations to this method, but none are as straightforward as just moving the folder.

DHCP Dropout

DESCRIPTION: Macs connected to the NT DHCP server suddenly loose their IP identity. (The MacWindows Server Tips page has some related information regarding BOOTP.) Here are some description of the problem from readers, and some hints as well:

Sept. 16, 1998
Scott Fraze

"The person will be cruising along just fine then suddenly loose TCP/IP connectivity. The AppleTalk stuff will still work, so they can see the NT-based shares just fine, but any attempts to surf the web or retrieve email fail. This has happened on several different G3's.

"The machines are running OS 8.1, with Farallon 100-base-T (PN996-TX) PCI NICs in them. When the machines refuse to browse the web, if you bring up the TCP/IP control panel .... the machine is set to DHCP lookup. Multiple reboots do not solve the problem, the only way I've been able to bring the machines back up is to switch over to the built-in 10 MB/sec ethernet for a day, then switch back."

Sept. 19, 1998
Gary Swick

I'm Gary Swick, the Systems Editor for The News Journal in Wilmington, Delaware. We're a Gannett newspaper with 160 Macs, 220 PCs and 20 NT servers. The NT boxes are both 3.51 and 4. We run both 10BaseT and 100BaseT, and also have DAVE on a few machines.

A couple of things I'd like to comment on: Using DHCP, we've had no problems with the Macs connecting when the DHCP server was on NT 4.0. We learned from Gannett's corporate operations center that DHCP has problems with NT 3.51, where it won't release IP addresses correctly. We'd get an error message like "A device with hardware address 00 00 94 7C AC 68 is using the IP address" Moving DHCP to NT 4.0 solved this problem.

Also, the older Farallon cards can't handle full-duplex at 100BaseT, so IP connections won't be completed.

Several of our Macintosh applications use TCP/IP to connect to servers, and if we have a problem with one connecting, we've found that pinging a known address will force DHCP to give that Macintosh an IP address.

Services For Macintosh is slow, much slower than Windows 95 to NT, or even DAVE to NT. If Microsoft doesn't fix the problems in the next Service Pack, we'll switch to DAVE and a total IP network.

Sept. 17, 1998
John Wolf

There are a couple things he needs to try:

Has he set the Macs TCP/IP control panel to "Advanced" and then used the option button to set TCP/IP to "Always Load"? This is important when using DHCP. If you don't set it to always load the TCP/IP stack, the Mac will cancel its lease after about 30 seconds of inactivity, and try and grab a new lease the next time TCP/IP is required. This just waists time, and may likely be the culprit.

You may want to pass along a similar problem that we have here and the solution. On occasion a Mac will lose IP connectivity. If you look in the TCP/IP control panel, it still shows an IP address as always, but only AppleTalk works. It turns out that out network switch caches the Ethernet address, IP address and AppleTalk address of each node on the network. Sometimes it just fritzes out and decides not to forward IP packets to that Mac again. The solution is to telnet into the switch and clear the cache.

April 23, 1999
Daniel Schwartz

"John Wolfe is in the right ballpark with his tips in the first paragraph, but it may be exposing a configuration problem in the DHCP Server: What is the lease time as set in the DHCP Manager? It can be set anywhere from a minute to a period of days. If you have a direct Internet connection with a small subnet and even smaller DHCP scope, then the lease times may be set pretty short. A 4 hour lease time is a reasonable balance for small LANs -- Under about 100 users or so. This time will vary, depending on the number of desktop computers, laptops, RAS ports, and such.

"Another solution, if there are enough IP addresses available, is to assign fixed IP address to the Macs; and then exclude them from the DHCP scope. You'll want to group them at one end of the subnet, along with printers, servers, and other devices that remain on constantly, i.e you only want to have a single excluded range (if possible)."

Folders or drive volumes that won't close

DESCRIPTION: A folder or a drive volume on the NT Server is open on a Mac, it can't be closed. Clicking on the close box has no effect.

[We can speculate that the problem is related to the fact that Apple's official line is that the Mac doesn't support volumes over 4 GB, even though it seems to work. Apple's official documents all advise people not to use partitions over 4 GB.]

Gregory Olen wrote back to say that he thinks the problem may be due to Mac users having the problem closing the window had the "calculate folder sizes" option turned on in the View Options menu for that particular folder. Other readers claim this is not the case:

Sept. 27 1998
Steve Mack

We experienced this. At the time, we were running a 200 MHz server with 100 MB or RAM. We replaced it with a Compaq Proliant 3000 server with 320 MB of RAM and dual processors and even after a fresh OS install and a full data restore the problem did not go away. Finally just for grins, I created a new folder with a different name, copied the files over to it and trashed the old folder and the problem immediately went away for good. I have no idea why this worked. The original folder was titled "Personal Folders". We have not had this problem with closing volumes. Just with closing a folder. By the way, windows machines did not have a problem with this folder.

This happened on a 50 gig server. We always keep Calculate Folder sizes turned off. We spent a small fortune on this one and Microsoft was unable to help and when I told them our solution, they said it didn't make sense. Eventually after about 5 - 8 minutes our window would finally close.

Oct. 13, 1998
Dan Schwartz

Here, the key word is "copied." When Steve Mack copied the files he also defragmented them, speeding up disk access tremendously.

A secondary cause for this is that the disk is over about 75%-80% full, causing the MFT (Master File Table) to become fragmented. In general, when you look at the display screen in Diskeeper 3.0, you want the top couple of rows (where the MFT is located) to be "clean." Generally, I turn ON the MFT logging in Diskeeper so I can review MFT status in the Event Viewer.

Illustrator files won't open.

Marc Goodman of the Weekly Reader is having a problem when he saves Illustrator 7.01 files to his NT 4.0 server. When another Mac G3 client tries to open the file, and error message says the file is corrupt. If he accesses the file by doing a peer-to-peer transfer from another computer, it opens just fine. We also have another response about the problem:

Sept. 17, 1998
John Wolf

We have also encountered problems with Illustrator and NT 4.0. Files opened in Illustrator occasionally indicate a "file not found" error, even though the file is plainly visible in the Finder and open file dialogs. Moving the files to another directory has solved it so far. I'm curious if the other person with this problem is using HP Openstore HSM on his NT server.

[Goodman replied that he was not using HP Openstore HSM.]

A Solution:

March 4, 1999
John Wolf offers a solution:

The problem we had intermittently opening Illustrator files I believe to have been due to the index corruption that happens when using the jumping icons fix under SP3. Since installing SP4, we have not had disappearing files, folders or oddities with Illustrator files. Of course we do have the dreaded 'Always rebuild index' issue with SP4, so restarting the server is now a 2 hour process instead of a 10 minute process."

Mac Viruses on large NT MacFile volumes

Several readers reported that they had no way check for Macintosh viruses on Windows NT Services for Macintosh volumes that are larger than 4 GB (possibly related to the AFP 4 GB limit issue). Symantec, however, says that Norton Anti Virus should work. Jeff Miller first brought this to our attention:

"Many of my clients are using Macs and NT 4.0 servers with SFM. I would like to scan these SFM volumes for Mac viruses (Worm autostart and Graphic Accelerator). Norton Antivirus (Mac and PC), Virex, and the plethora of shareware do not correctly scan large SFM volumes over a network and PC programs do not scan for Mac viruses. Any suggestions?"

We suggested running Thursby Systems' DAVE, which bypasses the Apple Filing Protocol. Several readers told us why running Thursby DAVE doesn't work. Thursby said it would, as did some readers.

Oct. 9, 1998
Jeff Miller

"Some smaller volumes will allow NAV administrator to run, but it usually locks up. Part of the problem I think is SFM volumes are still NTFS volumes, not HFS so the Mac apps don't recognize the file structure properly. (SFM does not change the volumes, simply interprets it for Mac.) The problem could easily be solved if someone would include Mac virus definitions with their PC software but as of yet no one does that I know of."

On October 11, Miller added:

"I and my consulting company [Technical Resource Systems] will continue to work on the issue. I have also contacted Symantec and they are looking into the issue from a Norton Anti-Virus Admin angle."

Oct. 10, 1998
Nate Caplin of Knight Ridder/Tribune Information Services

"Although I have not tried this yet (I could... I have DAVE and administer SFM volumes over 4 GB), this would probably not work reliably because when you access a Windows drive with DAVE, even though it may be an SFM volume, your Mac cannot access the files' Mac resource forks, which can contain viruses. Your Mac can't see the resource fork because NT Server ignores them when feeding files to Windows clients, which is what DAVE makes your Mac pretend to be. Furthermore, it's usually the finder type/creator codes (which are part of the resource fork) that identify file types (application, document, etc.) to Mac applications, including virus checkers, no doubt."

"Here's a workaround... Just run virus scans on folders less than 2 GB or 4 GB, rather than an entire drive."

Oct. 12, 1998
Wolfgang Klee

"I have mounted with Dave 2.1 a NT server (110 GB, 15 GB free space, no services for Macintosh installed). There seems to be no problem scanning my data folders with SAM. SAM worked normal and ended with the standard information about the number of scanned files."

Oct. 12, 1998
Teck Beng

"I have NTFS Volume setup as a Mac network volume. It is protected with Norton Anti-Virus for NT 4.0, it doesn't detect the DB virus that I put into one of the folders in the server. Using the scanner to scan through the server doesn't mentioned anything about it. I can only conclude that the definition (mine has being updated with 1007I32.exe) does not check for Macintosh virus."

Oct. 13, 1998
Jeff Walker

We're using Mac Virex and yes it does work on NT volumes mounted via DAVE. Weve become Virus experts in the last year thanks to the Autostart worm.

October 14, 1998

Dan Schwartz says he uses WormFood 1.3 for Mac OS. He also uses a Windows virus checker than can find Mac viruses. He writes:

"Sophos SWEEP can run on a NT/x86, NT/Alpha, NetWare, OpenVMS, OS/2, and Banyan Vines server platform. In addition, the InterCheck server has a Mac OS client, which is a simple Control Panel."

October 14, 1998
Ricardo S

We have checked Raid with 28 GB and 35 GB connected to Win NT via Mac and it works. We used Early Bird and WormScanner. They detected Mac virus and deleted them. You can download these utilities from our web site In our case we have a customer with about 25 Macs and 3 NT Alpha Server with 3 raid 5-set . We use both utilities to scan, detect and delete the viruses both from Mac stations and NT SFM-mounted volumes.

Info: The virus seem to infected the Windows NT server but we cannot notice any damage to the OS. With another case with customer working with Mac workstations, NT Alpha server and Unix OPI system and RIP the virus infected even the Unix Printspooler and created a lot of files called "No Name". We couldn't use the above utilities to deleted the virus from Unix. It has to be done manually.

Info 2: For those who has received the virus we suggest to install a control station with CD ROM, Jaz, Zip, Syquest to check media cartridge. This control station is not connected to the networks, use only as a media control. We checked a SyQuest cartridge in a network computer and before we controlled the media the NT Server was already infected (10-15 seconds after we put the cartridge into the drive!). We have not found any infected CDR-media yet, it seems that the virus cannot infected the CD during the "toasting" of data.

June 28, 1999
Rob Anglin

We are a production house that produces college textbooks for publishers. We have an NT 3.51 and an NT 4.0 server, both of which have huge Mac volumes. When I tried to scan some of these volumes using Norton AV using one of the client Macs, I got nowhere (it said collecting file information for hours).

The trick is drill down far enough in the directory structure and examine more manageable chunks of the volume. The downside is that it's time-consuming in that you have to sit there and point it to directory after directory.

Quark Scitex Spot Colour XTension and NT Server

Note: The solution is offered below.

Oct. 28 , 1998
Erik Ohlin

We had a 60Gig NTFS logical stripe of 2 30Gig Micronet Advantage RAIDs. The RAID controllers are integrated into the 30 Gig SCSI RAID, so NT sees the drives as single SCSI drives with no LUNs. We used Disk Administrator to stripe the 2 disks together to form a 60 Gig volume. We then published several (3 or 4) SFM volumes from root directories on this 60 Gig NTFS volume.

Our trouble seemed to spring up suddenly after about 2 months of use in this config. When opening and using large, complex Quark 3.32 documents (30-50 pages, hundreds of placed images/EPSs); Quark would suddenly "forget" about the linked files, thinking they were all "missing". Deleting and recreating the SFM volume (thereby rebuilding the AFP Index) did not solve the problem. Moving the Quark layout and associated support files to another NT volume fixed the problem.

We subsequently split the 2 30Gig drives to single NTFS volume and have yet to see the problem reoccur.

I should not, however, we have a 60-Gig RAID on the exact same NT server as the logical 60Gig stripe was. It is made up of 8 9-Gig drives in a RAID-5 config using and Adaptec AAA-133 controller and the Adaptec CI/O array S/W. It did not exhibit the above errors.

Oct. 30 , 1998 Erik Ohlin updates...

I have since delved a little deeper into the problem.

We run a Scitex-based prepress shop and use a special Quark Xtension called Scitex Spot Colors. Scitex Spot Colors Xtension parses placed EPSF files to determine if any of them have spot colors defined in order to add them to a common pallet within Quark. In order to parse the EPSF files, the files were opened from the NT. The files were indicated as "open" in the MacFile control panel on the NT.

These complex Quark layouts contained on average 50 pages with 1 unique support file per page and several (5-15) common support files. The files were indicated as "open" in the MacFile control panel on the NT. It seems that having more than about 64 (although I have not quantified this) open files from a single Mac client confuses Quark. Quark then sees the files as "missing."

The GOOD NEWS: If we manually disconnect the troublesome Mac client from the MacFile control panel (and thereby close open files forks), the files are then accessible by Quark once again.

I'm not sure why this problem has only occurred on the logically striped volume and not others. we certainly have produced similar work on the other server volumes.

March 17
Thomas Evers writes:

We have had the problem with the combination of Quark opening EPS files on the NT server. It spread around the department following the installation of the Scitex Spot Colour XTension. We experienced the missing files problem on just a few occasions -- but we regularly find that the EPS files enter a locked state -- where you can't re-save them. The easiest way to release the EPS files is to quit the Quark application on the Mac that caused the lock to occur. (Just closing the file that had the EPS links doesn't do it.) Sounds like Scitex needs to work on this more than Microsoft, though.

The solution:

Oct. 26, 1999
Torben Friedrichsen

The problems seems to be a "timestamp" Quark use on their documents. If the timestamp is different server/client between Quark think the picture/link is changed.

The solution is to use a timeserver, so both client and server have the same time always. There is a lot of Timeserver clients for NT there is freeware. It is already supported on the Mac (after system 8.0 I think).

It is normally on documents not used for a week or more and not on documents edited the same day.

A server crash or similar is enough to set the time just a few seconds or minutes back and the problem is there.

I have used that trick many times and it seems to have solved the problem.

Large volume problems

These are miscellaneous problems with large NT Services for Macintosh volumes. Some readers offer solutions as well. (We've addressed the problem of lack of accurate volume size reporting in volumes over 2 GB or 4 GB on the Server Tips page.)

Oct. 23, 1998
Dan Everard has no problems with Macintosh volumes on Windows NT Server that are under 70 GB in size. But with larger volumes (80, 112, and 120 GB), he reports seeing a variety of problems ranging from "missing" files and volume corruption to the server locking up.

Oct. 28, Nov. 20 , 1998
Joseph Haddon and David Dutt reported a problem backing up a 70 GB SFM volume. Since then, David Dutt found a solution. Since this was no longer unsolved or a mystery, we've moved this items to the Server Tips page.

November 23, 1998
Dan Everard

This information is included in the latest Diskeeper [Executive Software] release notes:

On very large partitions, Diskeeper may be unable to analyze or defragment the files on the partition, due to memory limitations. The exact values for this are determined on a case-by-case basis. The size of the partition, the cluster size of the partition, the number of files, the degree of fragmentation, and other factors affect the amount of system memory used by Diskeeper. For example, if a partition exceeds 60 GB in size or contains more than 9 million files, system memory requirements can exceed 1 GB.

May 14, 1999
Mickey Tan

I have a problem sometimes when I reboot our NT Server 4.0 SP3. Some of our shared Mac volumes do not automatically reshare. When I go to File Manager to Create a Mac Volume. It says after I set the name and privileges, " device not attached" and I can't share the volume. I have found that after i run chkdsk /f /r. I can now go back and do the same things and it works. Do you know what causes this and if there is an easier fix. We have a 70 GB partition that takes over and hour to run chkdsk.

March 1, 2001
Micha de Wals
The Netherlands

We encountered the same problems here. We have a 400 MHz Compaq server running Win NT 4 SP4 and have 1 G3 B/W running OS 8.6. We recently put the G3 into the network and put a 18 GB drive into the server. This 18 GB would be used for backup space for the Mac. Well we could copy small files but big files resulted in blue screens and restarts. After looking at this site we also decided to reinstall SP 4. With great result!! We can now backup onto the 18 GB without the blue screens!!

Word 8 Locks on large volume

Oct. 28, 1998
John Wolf

Here is a really odd bug I have been fighting with large volumes on NT4, although I am not positive it is strictly limited to large volumes. All of our volumes are 16GB or larger in size, the largest is 45.

On occasion, opening a Microsoft Word 8 file from the server causes Word to lock up. Most frequently we get the double arrows in the upper left, but no matter how long you wait, they never stop blinking and present the file. The workaround, and this is the really strange part, is to restart the computer, make a duplicate of the file on the server and then open the duplicate. The duplicate will open fine, and then you can close the duplicate and open the original with no problems. I imagine that moving the original to a different folder would also work, as this seems to be an odd privilege/index problem with NT4. With admin privileges, I can always open the troublesome files.

The Solution to the Mystery:

March 4, 1999
John Wolf

"On the Word 8 issue locking up opening files from an NT server, that turned out to be Norton Antivirus trying to modify the invisible 'NAV Quickscan 5.0' file on the file server. Replacing that file with a folder of the same name fixed that. I haven't had Word lock up opening files in some time now."

Defragmenting Services for Macintosh volumes

December 15, 1998 -- A reader told us that Executive Software (makers of Diskeeper) told him that Diskeeper can't defragment NT Services for Macintosh volumes, and that NT itself doesn't support it. Another reader had partial success with Diskeeper:

December 17, 1998
Gary Peterson

"We are using Diskeeper 3.0 on NTS4 with SFM. We have 2 SCSI cards with 4 SFM drives attached to each card. On one card, Diskeeper crashes every time we try to defrag a drive. I have to come in on a weekend and turn off SFM to defrag drives. On the other card, no problems. The autoscheduler kicks in every 12 hours and works fine on all 4 drives. No problems in 6 months."

April 12, 1999
Daniel L. Schwartz

It's important to note that the issues of defragmentation and file corruption are closely interrelated. With that in mind, let's start out with the basics as to the 3 general ways dual Mac files can be stored on a non-MacOS server:

1) Via native NTFS and SFM, splitting the forks into two streams of data. As long as the files stay on NTFS volumes, the streams will be preserved; so then everything will remain all hunky-dory... Diskeeper will transparently defragment the files per its normal operation.

2) Via combining the two file forks into a single fork file, such as the way MacBinary works. Defragmenters will work as they would on any DOS or Unix file; but this method involves extra CPU overhead and disk space on the Mac to split the 2 forks apart again so they can be used by the MacOS.

3) Via the PC Exchange Control Panel's method, of storing the Resource Forks in a separate hidden (to the MacOS) files. The Desktop files are also stored in hidden (to the MacOS) files. According to the support at Thursby, DAVE also works in this way.

More on Method 1: Native SFM/NTFS support. First, there was a fundamental shift in NTFS between NT4 and earlier versions: Prior to NT4, Executive Software licensed the NTFS source code from Microsoft and created special APIs to perform defragmenting. However, starting with NT4, Microsoft incorporated these APIs directly into the NTFS system.

Now, all any app needs to do is call these API's and voÏla - Instant NTFS defragmenter. And, since NTFS considers the two streams as a single file, then everything reads, writes, and defragments simultaneously. It is important to note that NTFS Cluster size is critical in 2 ways:

A) The defragmenting API's only work with cluster sizes of 512, 1024, 2048, and 4096 bytes;

B) 512 byte cluster sizes are more easily fragmented due to the 1024 byte file record size. This limits the effective cluster size range to 1024, 2048, and 4096 bytes. This is important because the CONVERT utility (FAT -> NTFS conversion utility) will only create 512 byte clusters... Pay attention to this when performing an NT installation on a fresh drive!

Note: AFP over IP (Apple Filing Protocol over IP) "husbands" Method 1 but can extend it to FAT partitions as well: Essentially, it is a hybrid of Methods 1 and 2; and normal defragmentation methods and corruption warnings apply.

More on Method 3: Splitting the Mac files into two discrete files. The advantage to this method is that one can store Mac files on any remote mountable volume - FAT12, FAT16, FAT32, as well as NTFS, as well as on 95/98 and NT/Workstation as well as NT/Server. The downside is that NT will see these hidden files as separate files, as opposed to a single dual stream file as in SFM/NTFS. An additional downside is that the 2 files required to make up a dual fork Mac file can become widely separated when defragmenting a partition, partially defeating the very purpose of defragmenting. An additional issue arises when these file pairs are stored on a NT File System volume: NTFS will not say a file has been written until it has been actually written... But what happens if your server crashes when one file fork has been written to its' file, but not the other? The two file forks now all of a sudden are corrupted due to "forking," i.e the versions are out of sync.

NOTE: FAT12, FAT16, and *I think* FAT32 drives can be directly mounted on a Mac via PC Exchange as well.

BEWARE: Both FAT12 and FAT16 are used in DOS floppies!

LPR (TCP/IP) printing problem from Mac OS through an NT Queue

December 29, 1998 -- Matt Harris of Mattel sends this report:

"We have an ongoing problem printing through an NT queue via LPR from Mac OS. The problem seems to stem from a problem with NT's handling of binary Postscript data from the Mac.

"Symptom: Intermittent print failure resulting in hundreds of pages printed with a single line of gibberish on each. Primary testing has been with Illustrator 7 and 8. In Illustrator, the problem occurs when the file is printed with binary encoding or when there is a placed EPS which was saved with binary encoding. We have not seen the problem occur when all parts of the document are created and printed in ASCII. Simple binary files print successfully on occasion. Strangely, the problem also effects MS Office, possibly because you cannot designate whether these apps print ASCII or Binary. I have confirmed this problem to exist on an HP 5si nx and an Apple LW 12/640.

"AppleTalk is not an option here, and our HP 5si nx printers do not handle multiple Macs sending LPR jobs simultaneously if they are sent direct to the printer (one of the jobs gets dropped). Apple printers are able to receive simultaneous LPR prints direct from Macs without incident.

"Printing direct to either model via LPR never results in the pages of gibberish we get when using an NT queue.


"Clients - Mac OS 7.6.1, 8.1, and 8.5.1 on Mac clients ranging from Quadra 950 to G3 Servers - NT SP3 with SFM active. No RAM or disk space limitations.

"LAN/WAN 2500+ clients; 250+ servers; AppleTalk is not routed for most subnets."

The Microsoft Knowledge Base article Q158903 describes the reasons for the problem, which have to do with assumptions NT Server makes about the encoding of Postscript jobs coming from various sources. The article recommends using AppleTalk instead of TCP/IP to print to these printers. It also recommends using ASCII or text encoding rather than binary, as Matt mentioned above. The article says:

"This is an option in the Postscript driver made by Adobe Corporation for 16-bit Windows and Macintosh clients. The Windows NT Postscript driver always uses text encoding. Desktop publishing programs (on any platform) often generate their own Postscript code, completely independent of the operating system's driver. ...programs capable of both binary and text encoding should provide a user interface to select either scheme. The ability to switch modes can usually be found in the Printer Driver dialog box."

Apparently, MS Office does not have this ability.

March 24, Jim Cowing adds:

"HP tech support will tell you directly that HP printers do not support binary data. Quark XPress has a workaround where you can designate that only ASCII data is sent, and AppleShare IP6.X print services has a setting where you can disallow binary data to be sent to the printer (it actually converts it to ASCII - kinda neat). But officially, you can't send binary data to an HP printer, unless you enjoy having the printer spit out several reams of garbage."

June 29, 2005
Yvan Rodrigues sent us a link to an article he wrote about this problem:

I have put a lot of work into this problem. I support about a dozen Apple clients in a heterogeneous environment with a Windows 2000 server. I have written an article on the problem and have several solutions, including a print processor that I have written that installs on the server and transparently converts the binary to ASCII.

He describes the problem in his article:

When printing from a Macintosh to a printer using any AppleTalk method such as LPR/LPD, IPP, Rendezvous, USB, etc., certain files will result in many "garbage" pages being printed, each one usually having a line or several lines of random characters.

NT Server slows to a crawl

There are several known problems that cause Windows NT Server to slow to a crawl, with near 100 percent utilization. There are other networking problems where the server seems to be fine, but file transfers between Mac and NT Server are very slow. These known problems and solutions are listed on the MacWindows Server Tips page. Please check that page first if you are having this problem.

Readers have also reported NT Server slow-down symptoms that don't seem to be caused by these known problems. These are reported here. One reader reports below that Service Pack 5 fixed this problem for him.

March 22, 1999
Dr. Karl Harrison
University of Oxford, UK

I was reading your report about Windows NT 4 servers slowing down because they get 100% cpu utilization. I have the same problem with my NT 4 server with SP4, when I run Marketwave's Hitlist 4 Pro (a IIS server log analysis program). It runs fine, if I run it as an application but as a service it occasionally does what you observe.

I run the analysis as a service at night and when I check the machine in the morning I find the server crawling along because it is at 100 % cpu utilization and all taken up by the hitlist service. I have to use the control panel services to stop it and then the slow down is corrected. Now if I run the program as an application at that point there are no problems and to analysis runs normally. Over a weekend this is a pain and I have had the server several times crawl along for 72 hrs (when the analysis should take ~30 mins.).

March 22, 1999
Nathan Zamprogno

I just wanted to add my comments concerning the NT slowdown issue. We have a very similar problem using Services for Macintosh under NT4 (SP3 *and* SP4). When the file server for Macintosh is started, CPU usage jumps to 100% and stays there. Strangely, the Print Server for Macintosh option runs without a hitch!

I've waited along time for a fix for this. Could you please add this to the commentary that is already on the site to see if people know of a fix. We need to get SFM back up and running!

October 12, 1999
Paul Williams

The real problem is [you] start SFM on the NT server and CPU utilization goes to 100% and stays there. It can go all weekend but never seems to get to where it is going. We have SFM installed now but do not start it! This gives us the MAC UAM volume but no more. ApplePrint services are fine so far the problem has been solved in different ways by different people or not solved at all. Some install with SFM active and it works others do not. We have tried both and still get nowhere. Could it be the binding to the Ethernet card? This is unexpected as the card is pretty normal no special functions other than a generic type.

November 10
Paul Willams

We have been monitoring the process so far and have now found out that SP5 has solved the problems. We were very wary and have just always started MacFile services after the server was up using the services panel in control panels. It has now been running for two weeks and has not been a problem. The server has not slowed down as normal and has not been out of action.

There has been no documentation to say that a problem has been fixed. Nor has there been a recognition of a problem occurring... Once again it has become one of the unsolved mysteries of Windows NT.

From Antarctica: File copies crashes NT SFM

We can now say that MacWindows has received email from every continent on the planet. We received an email message from Dean Klein, the network administrator for Palmer Station, Antarctica. His NT Server crashed whenever a Mac tries to copy files to it. Several people, including Klein, send in their solutions, posted below. Also, there are some versions of virus programs on Macs that cause this problem (see the MacWindows Server Tips page).

March 26, 1999
Dean Klein
network admin/LAN/WAN specialist
Antarctic Support Associates
Palmer Station, Antarctica


Dean Klein here from Palmer Station, Antarctica (if you look on a map, we're due south of Puntas Arenas, Chile).

We're having major problems with NT here. We recently received a HP dual processor server with all the bells and whistles. NT4 and Service Pack 4 loaded.

The problem? Whenever a Mac (using 8.1 or 8.5.1) tries to copy files to the server? Boom. Server down hard. It always reboots.

Any ideas? I'm fighting tooth and nail to keep Macs on the ice (it's a constant battle). Something like this just reinforces the wonks who want to ban 'em from the continent.

Any ideas? Any help you can provide or suggest will be greatly appreciated.

Klein may be alone at the bottom of the world, but it isn't the cold. Devon Copley of New York City is having a similar problem:

March 26, 1999
Devon Copley

I'm experiencing a frustrating problem with MacFile on my PentiumII/128 meg/SP4 system. I have a MacFile directory on a 10 gig partition, and after a certain number of file accesses from a new Mac G3 client, the server crashes with a blue screen and an error in the file system module. I can reproduce the problem by copying a *single* 40MB file onto the server! I tried downgrading to the 40-bit SP4 but it didn't help. Got no ideas as to what to try now.

Solutions to NT SFM Blue Screens

Several readers have written with different solutions to blue-screen problems. Several people mentioned virus protection programs. We have a tip about Virex and NAV on our Server Tips page, but several people also mentioned Inoculan

March 29, 1999
Bob Gordon

The only time I have seen NT freeze with Macs has been due to Virex 5.81 and Virex 5.9...They caused server freezing over the network. Once I tried the Virex 5.9.1 the problem went away. Also if they use MS Office 98 make sure the two upgrades are performed. Mac OS 8.5 upgrade and the privacy upgrade. This too caused a small problem.

March 29, 1999
Stephen L. Starkman

This is a long shot (cause I don't know the configs of Dean's or Devon's NT's) but:

Had very similar symptomology when we configured NT 4 SP3 with Computer Associates Inoculan Software. The version which ships on the CD will cause BSOD when Mac clients attempt file transfers of large files or numerous small files. Fortunately there is a free downloadable patch on the CA web site which solves this issue.

BTW, Inoculan has done a terrific job for us catching and removing Autostart viruses transferred on the net by the Mac clients. Very useful!

The patch and upgrade page is at:

March 29, 1999

Thought I'd let you know that we at our university support center finally found the solution to a Mac on NT problem that had been bugging us for months.

We had been experiencing NT server blue screens (hard freezes) whenever a Mac would create a new file or folder on the server and then either delete it or rename it. On a tip that Quota Advisor might be involved, we disabled the QA services and tried again; no blue screen! We could finally create then delete/rename files and folders on the NT server volumes without errors.

BTW, we notified Quinn ( publishers of QA) about the problem and they sent us a patch that was supposed to repair it. However, there is no info on their web site discussing the issue. And the patch they sent us did not fix the problem after all. We did finally get an upgrade from them that did resolve the problem, but I found it odd that they seem to be trying to hide the fact that their software is obviously causing problems out there on many NT networks.

Bottom line: Have your readers definitely get the latest version of QA (currently v4.0) if they use it on their NT servers.

March 30
Dean Klein
Palmer Station, Antarctica

Yes! Finally....We simply reinstalled Service Pack 4. SFM was active during the reinstallation...I figured this was the best way to go as maybe the SP4 would recognize the Mac needs and copy over the appropriate files.

Apparently that was the case. We've been able to really flog the server with Macs now (several 200 meg copies and deletions) with nary a hiccup.

March 30
Richard Berg

I found the hoxfix for a similar problem associated with NT 4.0 SP2. I have copied below the readme text which came with that hotfix. Since it gives info on the STOP message which is generated, this might be useful in determining whether the new problem is related, etc. This Hotfix cured my problem at the time. I now run SP3 and try to use lots of RAM in the machines.

There's a hotfix for Windows NT 3.51 and for Windows NT 4.0 SP2. It was fixed in Service Pack 3.

April 5, 1999
K. Scott Myers

I had the exact same problem after removing an older NIC card and driver. With the new card and driver the server would dump to the blue screen whenever I tried to copy any file to the server from a Mac. The only way I was able to fix the problem was to remove Mac Services, reinstall Mac services, and reinstall SP4.

October 22, 1999 Installing BackOffice

Stephen Baxter had the problem of getting blue screens when when copying files from a Mac client to an NT 4.0 SP4 server. He originally thought that turning off the gatherer service, but discovered that it was a peculiarity of the BackOffice installer that caused the problem. The BackOffice installer also installs Service Pack 4. The installer also requires that Services for Macintosh be installed after BackOffice. Unfortunately, this leaves SFM installed with older SFM files than are in SP4. Installing SP4 a second time upgrades SFM properly.

November 1, 1999

David Trask found yet another way to fix the problem of server crashes during Mac file transfer:

I read with great interest the problem and the fix from Dean Klein in Antarctica. I had the exact same problem on my Win NT server 4.0 with SP 4. I removed a NIC to upgrade it from 10 base T to 100 base T (new network installed) and lost my SFM. Upon reinstalling I neglected to reapply the SP4. After a lot of hours and searches for advice, I decided to reapply SP4 for the "heck of it" and voila! Problem solved. I had discovered during the process of elimination that my server only froze (and froze hard!) when writing to the server. I could download from the server (using Macs) all I wanted. Now all is well. So Dean you are not alone...

Macs crash when trying to delete files on NT Server

A reader writes:

I've seen plenty of similar items here, but none contained what I need to solve my problem, so I figured I'd pass this along. I'm running a mixed network (NT server 4.0 SP4, w/5 NT workstations, 4 Win 95 stations, and about 9 Macs). Two of the Macs are displaying problem behavior--both involving network access. In one case, the computer crashes when trying to delete files from a network resource (by highlighting them and selecting "Move to Trash"). This terminal recently had Norton installed and couldn't even copy files to /from the network without crashing-disabling the Norton extension solved the copying problem but not the deleting problem.

The other is a little worse. The Mac displays an "error type -110" when accessing the network--but only intermittently--this error prevents the user from accessing the network. Since this person is our managing editor and all our copy is kept on the server, you can imagine this is a big headache. Restarting tends to stop the error messages temporarily, but they're always back.

Both Macs are beige G3's running 8.5.1, with 96 MB RAM. Both have been checked with Norton Utilities and Antivirus with the most recent defs(both of which bring as many problems as they solve, but they've solved quite a few, so...) as well as the Disk Utility on the OS disk with a clean bill of health. Both have had clean installs done very recently and had their desktops rebuilt. Help!

The Mac giving the "error type -110" is indeed running [Norton AntiVirus] 5.0.3. The other isn't... the "error -110" still remains a persistent (and seriously aggravating) problem.

On May 26, 1999, Craig Cooley wrote to say "I had a similar problem that seems to have been solved by Service Pack 5."

However, on August 19, Roger Menge reported that Service Pack 5 does not fix the problem. He is running Win NT 4.0 SP5 server, Mac clients with 7.6.1 and 8.5.1--all clients occasionally exhibit the problem.

Menge also offered a temporary workaround: delete the Mac's Finder Prefs file in the Preferences folder (in the System folder) and restart the Mac. Menge says this is only a temporary solution, as the error will reoccur eventually.

On August 30, 1999, Matt Snider wrote to say that he solved this problem with a new SCSI/IDE controller card:

We had a client with the same problem on 2 Dell servers. We traced the problem to the Dell PERT card (their own SCSI/IDE controller card). We replaced the cards with Adaptec cards and poof, the problem went away, including problems with NT crashing with the blue screen of death with Macs copied files too.

We note that it could have been the software associated with the Dell card that caused the problem.

Mac files on NT SFM greyed out, unavailable from Sherlock ("files in invisible folder")


When you do Sherlock find for a file on an NT server and try to open it, the files are greyed out . An error message says the files are inside an invisible folder. The problem only occurs on Mac OS 8.5, 8.5.1, and 8.6, and not on Mac OS 8.1. The problem is caused by having the Mac volume at the NT drive's root level (see Solution below).

Eric Binversie was the first to report this problem (June 21, 1999):

I don't know if this is an unsolved mystery or not. I am getting the following message when I try to open a file in the "Items Found" box in Sherlock. "Cannot perform this command because "file name" is inside an invisible folder". This only happens when I am finding on the server, which is Windows NT 4.0 with Service Pack 4 installed. This problem occurs in Mac OS 8.5, 8.5.1, and 8.6. It does not occur when Mac OS 8.1 is installed. This problem also holds true to Mac G3 desktop, Mac G3 Minitower, Mac 9600, and Mac New B&W G3. I can see the file and where it is located at the bottom of the "Items Found" box, but the files are all dimmed and I am unable to click on them. Though I am able to copy the file and make an alias of the file.

June 22, 1999 -- Several readers seemed to confuse this with a similar (but different) known problem that was fixed with Mac OS 8.6 (which we list on our Mac OS 8.5 Issues page). However, Apple says the this older problem does NOT affect Windows NT. Also, several readers reported the problem with MacOS 8.6.

Workarounds (June 23, 1999 )

Several readers reported that installing the Find command from OS 8.1 on Mac OS 8.5/8.5.1/8.6 fixes the problem.

Eric Binversie found an easier workaround:

I have found a way to work around the problem, but it is not a solution. When the items are in the top-portion of the "Items Found" box, Option-Command Drag the file to the local hard drive to create an alias. Then double-click the alias and it opens the file. In the top portion of the "Items Found" box I am also able to Label the item; though I am not able to get General Information (command I).

Rick Zeman says OS 8.6 has indeed fixed the problem with his NT4/SP5 server. Binversie and other readers have reported that they still have the problem occurs with OS 8.5/8.5.1/8.6.


Rick Zeman (June 28, 1999) found this fix worked on his server:

If a Mac volume is created at the root (by highlighting c:\ in winfile), Sherlock will have the dimmed/invisible problem. If the Mac volume is create lower down (like c:\macvol or c:\macvol\files), Sherlock has no problems. Mind you, this is on a sample of _one_ NT4/SP5 server.

Other readers have verified that this fixes the problem, as well as other problems. Todd Parkhill said (June 29):

I moved the share point of my Mac shares from the root of the drive "E:\" to the main folder "E:\Software" and now I can not only use the find command w/o problems but can also do the Command-Click dropdown on the window title to navigate upwards in the folders.

The fact that this also fixes the window title bar navigation problem isn't a surprise actually, as we've had this posted on our Mac OS 8.5 issues page. From a description on this page, "SFM translates the volume's root directory 'hidden' flag as 'invisible' to the Finder, and the Finder behaves as such."

Quark Xpress and "Y2018" problem

Ingo Jonsson (July 1, 1999) was looking for Y2K problems with his NT Service Pack 4 server, when he found a Y2K-like problem with Services for Mac and Quark Xpress:

I found out a problem with MacOS 8.1/8.5.1 and an NT Server 4.0 SP4. If you put the Date of the NT-Server on 2018 and later, it is not possible to load Quark 3.32 and 4.0.x files in which images (eps,tif) are introduced.

I do not know, if this is only a RAM problem on the Mac's, because Quark will end its work with error code 1.

Do anyone know a fix? This problem does only affect with files where the files' date is later 2018.

Is it possible that Quark got a problem with dates later the year 2000.

We've recommended that Jonsson try NT Service Pack 5, but the problem could also be with Quark.

Problem with User Permissions: Macs freeze at logon

Christine Wong reported (August 18, 1999) of an odd problem with NT Services for Macintosh. It seems her Mac clients need administrative permissions in order to log on. Funny thing, it started with old Macs running 7.6.1, and now it's moved to newer Macs running up to OS 8.5. Wong thinks the problems occurred after a string of power outages. Her report:

We have had about 10-12 users encounter a problem where their Mac will crash right after connecting to the file server. If someone with administrative privileges on the NT server logs in to the Mac everything works fine. So I tried giving people 'Full Control' over their files instead of just 'Change' permissions. This worked for a while. But now I am running into cases where full control doesn't do anything to help. The Macs just lock up with anything short of administrative permissions.

The details are NT server 4.0 with SP4 installed. When the problem first started occurring it was on only Mac 7200/7300's with system 7.6.1. Then it moved on to 7500/7600's with 8.1, as well as a G3/233 with 8.5

Many of our machines started experiencing this problem after a string of power out and brown outs, but this is not always the case.


Richard Gynes (September 20, 1999) turns off "remember recently used items" in the Apple Menu Options control panel as a workaround:

I had a similar problem with Macs 8.6 and NT4 Server Service Pack 4. Turning off "remember recently used items" in the Apple Menu Options control panel is for me a workaround. The problem appeared on a series of Mac NT clients over a period of days - freezing when logging onto the NT server. A volume where no Mac files were stored would mount okay, but the volume with Mac files stored on it would cause a freeze on mounting.

Occasionally force quitting the Chooser when the Mac froze would leave the Mac volume with Mac files mounted.

*The problem appeared on one iMac straight after quitting word with a word file in the trash and trying to unmount the NT server* - is this related to the powerout crashes and the alias problem and SP 4?

December 27, 2001 -- This problem is problably not an Unsolved Mystery anymore. Joerg Erdei believes it is the same problem that is described in detail on the MacWindows Server Tips page, and we tend to agree. He says:

Here is why I think so:

1) Same problem (Mac freezes at logon, pre OS 9)

2) Administrative priviliges gives you the right to resolve any aliases in the Apple Menu, thus no problem; so this is consitent with the other findings

3) Same workaround

DHCP dropouts with DAVE and NT4 servers

September 12, 1999 -- Paul Dormer of the BBC describes IP DHCP dropouts on his Macs running DAVE getting IP addresses from NT DHCP servers.(The clients loose their IP addresses.) They symptoms are reminiscent of a problem reported at MacFixIt a few months ago, which blames OS 8.6. Here's Dormer's full report:

Basically we get disconnections resulting in error messages from Dave's NetBIOS control panel or the server volume becoming empty or confused. We believe this to be the IP stack, or this particular LAN. We have the same Mac build in another small (5 servers, 100 clients) NT only LAN and have no problems with Dave whatsoever.

The setup is like this.

Mac OS 8.6 clients using Open Transport 2.03 are first of all obtaining an IP address from one of many DHCP servers, then logging into a large NT Domain (i.e. 150+ servers and many 000's of Windows clients) using Thursby Systems Dave 2.1p3. The client mounts shares on one of the NT4 SP4 servers (No services for Macintosh running).

The problem.

A user will be working away happily and all of a sudden the server volume on the Mac desktop will appear empty or display the contents of the other share they were using. The connection to the server has been interrupted. This can happen while copying or saving files, sometimes NetBIOS provides the error message "The disk "Volume" cannot be used because it is no longer connected". At which point in time the server is fine because the Mac on the next desk is using it. This may happen 2 - 3 times per day per Mac.

Other points to note.

We have another separate LAN (5 servers, 100 clients) but with a Microsoft DHCP server, this has the same build Macs in it and they run Dave 2 with no problems. In the large LAN where the problems are there is also an enormous AppleTalk Zone with 200 printers & 50 Macs. The Macs are of all types; 7300's, 8600, G3's. In the larger LAN I would also expect there are many other types servers resident and the DHCP servers are Unix.

September 21, Paul Dormer adds:

John , we have now confirmed this as occurring only on Macs which use DHCP. A few weeks ago we made fixed IP's but still used DHCP, then we moved to manual configuration of the TCP/IP control Panel and the disconnection's were no longer occurring. One Mac was put back onto DHCP and suffered again. What is interesting is that it is more prevalent in one physical area of the network.

It seems to be the Open Transport DHCP freeze as followed on I think the thing to get across to readers is that it only happens on certain types of networks, as we have proved, by having the same Mac build in 2 LAN's. As to what exact network configuration causes it I couldn't tell you yet because I neither have enough information or expertise on our large TCP/IP network.

The combination of MacWindows and MacFixIt have been very helpful on this subject. Now all we have to contend with is the crashing of the finder on certain machines when copying to NT4 shares via Dave.

Saving a file to NT volume with more than 500 items

This now appears to be a Mac OS problem, so we've moved this discussion to our Mac OS page.

Service Pack 6: Mac client performance degrades

December 23 --- When Steve Crossman upgraded his NT 4 Server from Service Pack 3 to 6, performance of Mac clients was good. However, with 33 GB of files on the server, Mac file transfers have slowed dramatically.

We just upgraded our servers with new hardware ( Pentium II 333, 256mb RAM, 60GB RAID 5 Ultra 2 SCSI) and went from NT4 SP3 to SP6. We see a 200 percent increase in file transfers for Windows PC users, but for Macs, it is painfully slow. We did not see the slowness during our initial testing.

During testing, with two Mac clients, performance was great over our previous server. But now that we have placed 350,000 files and 33GBs on the server, all Macs file transfer are very slow. The time to transfer a 10mb test file on a Windows PC is about 4 seconds, on a Mac it may take 1 minute or more.

The only software added to the NT4 SP6a was Network Associates Netshield, with all the latest virus engines/DAT files and Veritas Backup Exec v7.3.

The only thing we did not have on during our initial testing was Netshield and we had v7.2 of Backup Exec installed.

SFM was installed after the initial NT install and then we applied SP6, as I know that adding SFM after the SP is a bad thing. Any information that you can share or post to your web site so that I might receive feedback would be greatly appreciated.

Cause: Misconfigured switch.

January 10, 2000 -- Steve Crossman found the cause to be a a misconfigured 100 MB switch.

I wanted to follow-up on a previous email that I sent you in the beginning of December which you posted on your NT Unsolved Mysteries page regarding slow file transfers to Mac clients with SFM and NT4 SP6 upgrades.

To work around the problem, we installed MacServerIP and found that it solved the problems we were having. What I did find was on older Macs with 7.5.5 MacOS that logged into a MacServerIP share, it would use AppleTalk instead of AFP over IP. The result was the same slow access experienced on SFM shares. This made me think that the problems were not with SFM but with the hardware we were using routing AppleTalk packets.

I reverted back to SP3 and all hotfixes we previously had on our older server and problems still existed, so it wasn't a SP6 issue.

The bottom line was this, a misconfigured 100mb switch that was set to 100mb half-duplex where as the NIC in the NT 4 server was set at 100 MB full-duplex. After changing the switch to full duplex all problems disappeared. (For more on this topic, see the NT Server Tips page.)

We are however going to dump SFM and use MacServerIP because of:

  1. It is memory intensive compared to MacServerIP
  2. MSIP is faster when testing using the Helios LanTest application in almost all tests
  3. It correctly reports total volume size and remaining free space on the server
  4. It doesn't have the 65535 file limit SFM has
  5. It rebuilds Mac indexes much faster than SFM should the server crash or need to be rebooted

Macs get Access Denied message within Photoshop

January 21, 2000 --
Teresa Wenrick

We have recently installed a new NT Server and we are having problems on two Macs receiving a "Access Denied" error when trying to save things into this new server. They are saving the files out of Photoshop or Linocolor.

They can save the files to their desktops and then drag them to the server, but cannot save directly into the server. The problem is inconsistent also, one day it will happen and the next day it doesn't. If I log them out on the Mac and log in as as administrator and then log out and relog them in, without saving their login name, and then log them in via the Chooser, save their name and it solves the problem temporarily. One of the Macs is a Power Computing clone running OS 7.5.3L and the other is a G4 running OS 8.6. The server is Windows NT V4.0 running Service Pack 5.

I tried installing the Microsoft UAM on the Macs and it made the situation worse.

Cause and Solution:

January 24, 2000 -- Many of our readers have seen this problem. Most believe that the cause is temp files written by Photoshop. Here's a summary, with reader comments following:

  1. Certain versions of Photoshop try to write temp files that c at the root directory of the server volume. If the user does not have access to the root directory, the "access denied" message appears. The solution is give users root access.
  2. Readers seem to agree that this does NOT occur with Photoshop 5.2, but does with Photoshop 5 and earlier and 5.5.
  3. Readers indicate that this occurs with AppleShare IP and NetWare servers as well.
  4. Robert Hammen said this is a long-standing one for applications created in MacApp.

Rick Zeman saw this with NetWare:

This is a bit of a guess since she didn't supply any version info, but Photoshop 5 (not 5.02) and earlier need to be able to write to the root of the server volume for its temp files. No write access, no save. (Never seen this under NT, but since I'm a NetWare admin, I really wouldn't.)

Rob Minch:

I have been getting the same message as Teresa Wenrick is when saving from Photoshop 5.5 to our NT 4 server with SP6a. But the problem is only seen in Photoshop 5.5. If I go to another machine with Photoshop 5.0.2, I don't get the message.

Jim Bunk:

I am not 100 % sure that this e-mail will solve your problem but programs like Photoshop and Word need to write a temp file before the actual save takes place. If the user does not have access to the root directory then there will be a problem.

Robert Hammen:

This problem may be related to a long-standing one for applications created in MacApp where, if applications don't have write access to the root level of the volume (for their temp files), they can generate errors like this. I'd suggest the user open up full write/access privileges to the root level of the volume and see if that resolves the problem...

Bill Kearney mentioned that this type of problem has been discussed on the AppleShare IP mailing list. He has a slightly different theory:

I bet it's the Temporary Items folder problem.

I'm not clear on the details but apparently there's something the client software want's to do that involves using a hidden folder on the server. If this folder isn't configured "right" then problems occur.

The AppleShare IP mailing list has been discussing this for a while. I've not been following this issue so I can't comment.

What I suspect is happening is that the client software can't write a temporary file. What might have happened is that ANOTHER user has created this temporary folder since it wasn't there the first time. Now that folder is owned by the other user and the new user can't "get" to it.

John Chapman sent some information on Access Denied situations that can occur in more general situations, including links to several Microsoft Knowledge Base articles:

I've seen this sort of behavior a few times. One possible problem is the way NT handles file/directory caching by default. This can not only impact Macintosh users trying to write files, but can also affect Windows and FTP users; it is most often seen on servers running IIS. Please refer to the following Microsoft Knowledge Base articles for more information and workarounds/fixes:

Knowledge Base article Q191742
Knowledge Base article Q182626

(Note - the above fixes involve changes to the Registry; I strongly recommend making a good backup before using RegEdit just in case something goes wrong!)

Another possibility occurs with multiple NT domains; see Knowledge Base Article Q131231.

Clients of NT Server can't save to disk

This problem temporarily prevents users from saving files to an NT Server. Several readers have suggested that Microsoft Internet Information Server (IIS) temporarily locks files. We first have some descriptions of the problem followed by explanations of the possible cause.

Note: Microsoft Knowledge Base Article Q182626 describes a problem with Internet Information Server (IIS) that causes an "Access is Denied" message when trying to save the ISS FTP server on Windows NT.

The problem:

Victor Wise first reported this problem with Windows NT Server 4 SP5 on June 22, 2000:

A user has a volume mounted with SFM on MacOS 8.6. If they open a file and edit it once or twice... they can't do a "save" back to the volume--it forces them to do a "save as". If they wait long enough they can eventually save. Is there some sort of timer or keep alive that would stop the save vs save as?

Other readers have reported it with Service Pack 6a. Craig Arko (June 23, 2000) described the problem further:

I've been seeing this on NT 4 with SP5 and SP6a installed, MacOS 8.51, 8.6 and 9.04. I've noticed it particularly when in BBEdit changing web pages. The file appears to be locked, forcing a "Save As" with a new name. One can easily delete or rename the original file in the Finder (using SFM), but cannot save over it. The vexing part is, the problem is not 100 percent reproducible, i.e., sometimes "Save" works. For all I know, Internet Information Server (4.0) may be the culprit, or an NTFS bug. I don't recall this happening under SP4.

Possible cause:

Jason Bartlett offered a solution. (Barlett's group experienced the problem with Photoshop.) He found the problem to be the AppleShare client 3.8.4 and 3.8.5. Going back to version 3.8.3 fixed all their save problems. However, this did not work for Craig Arko:

Unfortunately, I'm using AppleShare Client 3.8.3 (installed with 8.6) and the problem still occurs. An error -61 is what I get from BBEdit. I'm becoming fairly certain that IIS is locking the page and taking its sweet time about unlocking it.

Other readers agree. Rick Zeman proposed an explanation:

IIS caches writes so his success or failure is dependent upon whether IIS has flushed itself or not.

Bruce Bowden also suspects IIS, but doesn't run SFM, and has the problem with DAVE. He also sees the problem with Windows 95 clients:

This is only applicable to files being published on the web through IIS. If a file is accessed by a web browser, IIS appears to write protect the file, preventing saves. For our production sites, with lots of users, we solved the problem by using FTP to update files. For the test site, where only a few users are viewing the files, we sometimes have to make sure that nobody is viewing the file in a browser before editing.

This is not a consistent problem, but it is browsing the pages that causes it for us. We don't have SFM, our IT people are not that cooperative, instead we use DAVE. Interestingly, this is much less of a problem for the Macs than it is for Windows 95 clients. A colleague who had been using Windows 95 found editing web files almost unworkable. I let her use my Mac while I was away, now she won't give it back!

Duplex problem with new Power Mac Gigabit Ethernet?

October 5, 2000 -- Jesper Jurcenoks noticed that five new Power Mac G4s (dual 450's with gigabit Ethernet) connected to a 100 MB network experienced slow file transfers that ground to a halt. Setting the hub to half duplex (and 10 MB) fixed the problem, as did installing a 100 MB Ethernet card in the Macs.

This sounds similar to a problem of mismatched duplex settings the switch and a NIC in a NT server PC, where readers recommended changing the setting from Autosense to full duplex:

On both a switched network or on a 100Mbit HUB without any other traffic performance is fine. If you add traffic to the network then sending performance drops to nothing.

Ex. on a network where 10 Macs are reading from the server, writing to the server and printing, the G4 will read a 100Mbit file in about 45 sec. To write the same file to the server, will take anywhere between 10 minutes and 45 minutes. A 100Mbit G3 on the same network at the same time, will save the file in 2 minutes, to the same server.

We had one of the G4's to print directly to a printer thru a hub (no switches or anything else in between), speeds was 25-50 Kilobytes a minute.

We then canceled the job and printed from a G3 with speeds in excess of 40 MB a minute.

There is currently (October 1st 2000) no patches or software updates on Apples homepage to solve this issue.

I have found only 2 workarounds for this problem :

1) Set the switch to 10Mbit (ten Megabits) and Half duplex, for the port that the G4 is attached to, This will give consistent speeds much better than before.

2) Buy a 100Mbit PCI board and put it in a slot in the Mac.

Word 2001 file corruption on NT4 and Win 2000 volumes

January 22, 2001
Lieven Baeten

We have Mac and Windows clients and an NT4 SP5 server. A strange problem occurs with Word 2001 saving changed documents to some directories: Word will start saving the file, but when the progress bar nears completion, a message appears telling that "Word cannot complete the save due to a file permission error". The name of the file is changed in "Word Work File xxx" and it is no longer visible in the Finder. Looking further reveals that there is still a hidden file "Word Work File xxx" in the directory. The 'permission error' does not prevent you from creating and saving a new file in that directory, but all subsequent saves result in the permission error and file corruption. 

This does not happen on all SFM directories, only in very specific directories (so probably there is something of permission conflict, but Word 2001 only detects is too late). And also the problem does not occur with Word 98.

Possible cause:

June 4, 2001
Dave Han

The mystery "Word 2001 file corruption on NT4 volumes" located on your NT Unsolved Mysteries page might be due to read-only permissions on the directory. If the directory is set to read-only, that would cause the problem described, as Word won't be able to create the temporary files that it needs for every file.

Suggestioned workarounds

November 15, 2001
Bas ter Beek

After upgrading to Office 2001 we were receiving problems when Multiple "limited" users 9.2.1 saving directly on NT4 and Win2K file servers. During save the following error message appeared: "Word cannot complete the save due to a file permission error". Resulting in corrupted Word Work files on the server. Some other applications received errors while saving on our NT servers.

Solution 1: When turning of Multiple User or when using the owner account we received no errors.

Solution 2: After Turning off realtime "antivirus" scanning on our NT4 and Win2K file servers the problem went completely away.

We use OfficeScan form TrendMicro. After this saving was much faster, Open dialogs were faster and file corruption errors where gone.

Found similar solutions on Microsoft's website regarding NAVirus realtime scan resolving in the same error for Windows clients.

December 28, 2001 -- Joerg Erdei believes this is related to an issue on our Windows 2001 page that describes a conflict with real time scanning and file permission problems caused by Trend Micro's ServerProtect virus protection software.

Performance problem with saving files to NT SFM

Several readers have offered workarounds, reported below.

Note: readers have also reported similar problems with AppleShare IP servers.

The Problem

November 28, 2001
David Theoharides

We have come across a new problem using iMacs and iBooks w/ OS 9 and a NT Server 4 with latest Service pack 6a. The server has 512 MB of memory and does file sharing for the Macs. The problem does not appear with Macs using OS 8.x or lower.

When a user using Os 9 or 8.x opens a mounted network volume on the Desktop from the NT server they can quickly look at all the the folders and files on the volume. This works well in both OS 8 and 9.

But when a user is using an application such as Word 2001 or AppleWorks in OS 9 and tries to SAVE to the network volume, the new file management window that opens in the application takes several seconds (and at times up to a minute) to "settle down" before the user can actually type in a file name and save. "Settle down" means the file save window appears to be SORTING the folders- they actually appear to be being put in order. There are 5 main folders on this network volume (from the NT machine), with about 120 student folders in each of those folders. There are likely 10-30 files in each folder.

When we use Word to save a file on a machine using OS 8.x, the file save window performs quickly with no delays.

Apple suggested upgrading the service packs on NT... we had already done that. We also tried upgrading one machine to OS 9.2. No difference.

My Tech guy also says that when using Word 2001 on an OS 8.6 machine that the file saving window is the same window style that is used in OS 9 and that file saving using a Word and OS 8.6 with this window is noticeably slower then using AppleWorks 5 on the 8.6 machine. On the iMacs with Airports it is unbearable and essentially unusable in the classroom.

December 3, 2001
Jonathon Blissenbach

I use four Windows 2000 servers that the students log into at our school using Multiple Users through a Macintosh Manager server. Anyway, I think this is what you are doing as well, and I've had no problems whatsoever, everything's worked perfectly pretty much, except for one iMac. If I logged in as the owner or administrator, it went through fine and dandy, but if I went in as a student it froze exactly like you say. I never solved the problem, just replaced the computer with a new one and have the old one sitting on my floor.


December 3, 2001
David Theoharides

With further testing we have narrowed the problem down to the new dialog box that is used for file opening and saving with AppleWorks 6 and Word 2001. In an experiment with an OS 8.6 machine and an OS 9.1 machine we used Word 98 which uses a different file dialog box.

These dialog boxes open instantly. When using AppleWorks 6 on these two machines and opening the file dialog boxes, they take a long time to "settle down" and let the user save or open the file. Apparently these new Dialog boxes have extra features and code that is not efficient in a Network situation. We have shut off recent items and servers in an effort to get these newer dialog boxes to respond quicker.

Today we took the Volumes and instead of having 120 folders - 1 for each student - we created folders like A-F, G-O, etc... and placed the individual student folders in them. These dramatically improved the response time of the newer Dialog file save/open boxes.

December 3, 2001
F. Stuckey

Been there...done that.

While serving as the IT Director for Texas Lawyer we determined a need to install SP6a on our NT4 PDC. Immediately, our Mac users noticed the "sorting." On some occasions the "sort" would take >10 min, as we had approximately 100 gigs mounted for Mac and some of the folders were extremely large. Shortly afterwards, we noticed an even larger problem. When a user would save a large file (over 3 MB), it would spawn a memory dump on the NT4 SP6a box. I immediately called Microsoft, and was told that it was a known issue, and to call another number (at a cost to us of $245.00).

December 3, 2001
Derek Smith

In our setup we realized a performance gain a few years ago when I set the server folders to List view and show only the name of the folders: no date, size, kind, etc., and made sure that Calculate Folder Sizes was unchecked. (We migrated from NT SFM to 2K SFM this summer & the technique is still valid.)

Also, these settings must be made when logged in as the Server Administrator if they are to stick for all users.

December 3, 2001
Patrick Exner

Try to delete (completely) the folder named "Servers" inside the System Folder. This may help.

December 5, 2001
Peter Lennon

This was reported on the AppleShare IP list and may affect NT machines, though I can't confirm it. The model for sharing is different, the permissions structure is different, and I don't use NT for file sharing in my school - Macs and PCs share from ASIP.

However, it seems that some apps require an invisible "Temporary Items" folder on the volume to which they are saving - not simply on the boot volume of the local HD. The user must have R/W permission to this folder.

It is a pain in the neck, but not difficult, to fix on ASIP and I have posted a solution on the relevant list. It involved using ResEdit to make the folder visible - actually creating the folder or duplicating it in some instances - and then setting the privs. Can be done from a client.

As I say, I don't use NT in this mode, but it may be worth someone in this position following up.

December 12, 2001
Peter Lennon

I've thought a bit more about it. It would probably NOT affect a site which shared every user's folder as a volume, i.e. so that the folder appeared as the root volume, in the way that they appear under Windows.

However, if the NT server shared a folder CONTAINING a lot of user folders, and as I understand it, that's what you have to do if you have a lot of Mac users under NT, where the users have r/w permission on their own folders but not at the top level of the share, then this solution probably applies - but it only affects MacOS 9.x users - well, at least AFAIK. I don't have any MacOS X clients yet.


| Top of This Page (table of contents) |

Other MacWindows Departments

| Solutions | Tutorials | Tips | News Archives |
MacWindows Home |

This site created and maintained by John Rizzo
Copyright 1998-2001 John Rizzo. All rights reserved.