Running a W2k3 server with RAID 5. Over the past week or so, I noticed a significant slowdown in transferring files. It's been up and running for well over a year, so I decided it was time for a reboot. When I got to the login screen, it was completely locked up, so I did a hard stop and start. Now my Mac can connect smb, but not afp, so I rebuilt the Mac share. I
HAVE to have afp for our version of Rampage (later versions can smb, but not ours). Still no afp... but I remembered that it has to reindex 500gb of files, so I'm okay with it taking a little while to do that. Finally, it finishes, but then the server locks up again. Another hard reboot and I look at the log. Looks like the BBU for the RAID is faulty, but this should just slow it down, and not lock it up, right? I'm probably going to call Proactive Technologies and get a new $250 battery today, but I also noticed that the usual .DS mac bullshit seems to be missing from the directory. Did some legwork and found this gem that solved my problem:
QuoteIf you copy or move files to a Macintosh volume on a Windows NT server, the Mac clients on the network might not be able to see these files, even though the PC shares can. This problem, which happens with multiple versions of the Mac OS, lies with the volume index file that tells the Mac clients which files are available on the networkshare. You can intentionally corrupt this index file and force NT to rebuild it so that the Mac clients can see the files you copied or moved.
If the problem exists in a volume that is part of a directory (e.g., d:\public), use the following command syntax at the command prompt:
dir > D:\PUBLIC:AFP_IdIndex
If you're rebuilding a root drive share (e.g., d:\), use the following command syntax:
dir > D:\:AFP_IDIndex
If your path includes spaces, you must enclose the path in quotes. So, if the Services for Macintosh (SFM) directory in the above example was I:\Mac Volume, you would use the following command syntax:
dir > "I:\Mac Volume":AFP_IdIndex
Note that this command will intentionally corrupt the Macintosh volume index. When you stop and restart SFM, the corruption forces NT to immediately rebuild the volume index file. If you see an Access Denied error message, files might be open on the volume or PC users might be accessing the shared directory. Disable all programs and file sharing to prevent this error.
After NT finishes rebuilding the index, the OS will log an event in NT Event Viewer. If the volume is large, it might take several minutes before the Macintosh client can see all volumes and files. Avoid stopping the SFM service during this time.
Should I still bother with the battery?
Yes. It's critical infrastructure right? Why get cheap now?