# What's With Leopard Permission Repair?



## SINC (Feb 16, 2001)

Ever since I left Tiger behind, permission repairs have sucked. I tired again tonight and when I saw, "estimated time less than one minute" I had hope.

Eight and one half minutes later, I got this on my brand new MBP:

Repairing permissions for “Macintosh HD”
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner" has been modified and will not be repaired.
Permissions differ on "private/var/log/secure.log", should be -rw------- , they are -rw-r----- .
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

Permissions repair complete

When will Apple do something about this now useless and aggravating feature in Leopard?


----------



## Cole Slaw (Aug 26, 2005)

I get the same thing when I repair permissions in Leopard.
It just seems to go on forever compared to how it worked in Tiger.


----------



## Jeepdude (Mar 3, 2005)

For some reason, it takes forever.

There were a few threads in the Apple discussion forums on this. They suggested reinstalling 10.5.1 update via download/install (as opposed to software update).

EDIT: An Apple Tech Note talks about this, but only says these messages can be safely ignored.

For me it cleared out all those error messages, but the detect/repair still takes a while.

I'm on a MBP 2.16, 3GB ram...


----------



## Orion (Apr 16, 2004)

I've read the same as what Jeepdude mentioned (download and install) and that's how I updated.

So far as I can guess it seems that Apple has to figure out just how the new Access Control Lists will be handled by Disk Util. Actual permission repairs seem reasonably swift once they start. DU may be comparing the ACLs with the Unix permissions which seems to take time.

This is all my opinion / guessing. No proof.


----------



## GratuitousApplesauce (Jan 29, 2004)

OK, I'm waaaaaaaaaaay out of my depth here and I seem to be having some very annoying problems with permissions under Leopard.

I was trying to move some of my music files around within my /Users/(myStandard-nonAdminUser)/Music folder and migrate a bunch of backlogged .mp3s into my iTunes folder Music/iTunes/iTunes Music folder. I discovered that to move them or change the names of any of the folders and files - many of which I had created - I was being prompted for my admin password. In some cases even the admin pass wouldn't allow me to change the names.

So I tried fixing the permissions from within the Get Info window. No effect. What I saw on the Get Info window of the affected files was a note under Sharing & Permissions reading "You have custom access" instead of the usual "You can read and write".

I knew enough about using the Terminal to be able to look at files in there and view the exact permissions. The affected ones were -rwx---rwx+ or [email protected]

I started looking around the web for how to fix this and found a page on the macosxhints forum, where some quite knowledgeable people mention how Apple has introduced ACLs (Access Control Lists) into Leopard. Permissions Nightmare With Leopard

This is starting to look like a nightmare to me. 

I followed the advice of the final post in the thread which recommended using the command *chmod -R -a# 0* to eliminate the ACLs attached to the permissions. I did not apply this to my whole home folder as was recommended, but just applied it to a few directories within the Music folder to see if it would work. It seemed to be working OK, but the first thing I discovered was that it was going to be tedious. The change doesn't seem to propagate downwards through many or all directories. I tried applying it up the directory chain a bit but it didn't seem to work in that case either.

So far, this seemed somewhat annoying until I realized that this permission problem is through files all over my home folder and Documents folder. Now I'm really annoyed. I tried making changes to the names of graphics files, spreadsheet and text files throughout the folder and found that I couldn't do this or put them in the trash without an admin password. In some cases the admin pass wasn't enough and in one case I found that even using my root password didn't do it. Now I'm more than really annoyed.

At this point I'm looking at a huge amount of work to downgrade to Tiger or methodically go through a ton of files using chmod.

I'm not sure what to do at this point since I don't really know what's going on and I don't want to make anything worse. This could be a case where a little bit of knowledge is a dangerous thing, although I was being quite conservative about any of the Terminal changes I made. From what I'm reading on the web about this it looks like Apple has really dropped the ball with their permissions implementation in Leopard.

Anyone have any ideas? 

Is this what it's like in the land of MS Windows?


----------



## MacDoc (Nov 3, 2001)

You'll notice that several utilities, SuperDuper, iDefrag, Onyx etc are not yet up to Leopard support.

There are clearly still some issues in handling the changes in the deep file structure.


----------



## chas_m (Dec 2, 2007)

*Re: What's With Leopard Permissions Repair?*

Permissions repair under Leopard does not take noticeably longer (though I'm sure it's slightly longer) than it did in Tiger.

I did an A&I which cleaned up my "highly tweaked" system nicely, maybe that's the reason -- I don't know.

This thread got me curious so I decided to time the repair just now: 1 min, 10 seconds. Seems a bit slower than Tiger but nothing to write home about ...


----------



## biovizier (Dec 21, 2005)

GratuitousAppleSauce said:


> I discovered that to move them or change the names of any of the folders and files - many of which I had created - I was being prompted for my admin password.


There could be more than one cause for this. For one, there appears to be a bug in how permissions work in Leopard (i.e. they don't work as it is supposed to), affecting both the "Finder" and unix layer. Another possible issue is ACLs - in Leopard, users' "home" folders and most of their standard "top level" folders ("Desktop", "Documents", etc.) have the "group: everyone deny delete" rule that prevents deletion and moving (renaming counts as removing) of any items with that ACE. The problem is that the stupid new "Get Info" interface does not show this rule, yet allows a user to apply it to "enclosed items". So a user might make an intentional change to the permissions on eg. the "Music" folder to allow someone else access, then use "apply to enclosed items", not realizing that they are also transferring the ACLs at the same time. Then, since "Get Info" doesn't even display negative ACEs, the user can't get rid of it (or even know that they are there) without going to the command line.



GratuitousAppleSauce said:


> The change doesn't seem to propagate downwards through many or all directories.


The command 'chmod -R -a# 0...' just removes the first rule of the named item. If there is more than one rule, the former rule #1 becomes rule #0 (and so on) and the command would have to be repeated until all rules are gone. And as you noted, the command only acts on the named item but not on any contents if the item is a directory. 

Assuming you own all of the files, all ACLs on a folder and it's contents can be stripped using:

```
chmod -RN /path/to/folder
```
Note that this may not be what you want since an ACE is used when access rights to some user are granted using "Get Info" - that would be stripped as well. But you could just add those back (and use "apply to enclosed items" at that point). After doing all that, if the folder being worked on is the "home" or one of the "standard" folders, it might not be a bad idea to put the original ACE back as well, which was probably intended to prevent the user from accidentally deleting eg. their whole "Documents" folder (something a poorly designed "column view" increases the possibility of). i.e.

```
chmod +a "everyone deny delete" /path/to/folder
```


----------



## hayesk (Mar 5, 2000)

Here's an idea. STOP repairing permissions. Seriously - this is such a troubleshooting red herring it's not funny. Back in MacOS 9 and earlier it was "rebuild your desktop" and "zap your PRAM". Now it's repair permissions.

What do you think will happen to your Mac if your secure.log has permission -rw-r----- and not -rw-------?

If you do not know the answer, then stop worrying about permissions.


----------



## monokitty (Jan 26, 2002)

hayesk said:


> Here's an idea. STOP repairing permissions. Seriously - this is such a troubleshooting red herring it's not funny. Back in MacOS 9 and earlier it was "rebuild your desktop" and "zap your PRAM". Now it's repair permissions.
> 
> What do you think will happen to your Mac if your secure.log has permission -rw-r----- and not -rw-------?
> 
> If you do not know the answer, then stop worrying about permissions.


:lmao:

Excellent post!


----------



## MacDoc (Nov 3, 2001)

Yeah sure ...ignorance is bliss 

The ONE time when repairing permissions is a useful exercise is when there a upgrades and installs going on and I can guarantee that's the case with Leopard adopters.

a sensible response to another "repairing permissions is meaningless": post.



> Actually, as an IT, here's the real question. Does Repair Permissions ever break anything? As far as I know, the answer is no. Do things get fscked up by various installers, apps, god-only-knows-what over time? Yes.
> 
> So adding repair permissions to your laundry list of stuff to try is simple, takes 60 seconds to try, and doesn't cause more harm then was already present before it happened. *Also, it sometimes works.*
> 
> That's basically end of story in my book. It stays on the list.


I concur....sometimes it works and it does no harm.

Case in point



> I actually had a user complain that the WebObjects licence installer would validate the licence key but would then fail, saying "could not write licence file". Rather than pull up the WO5.2\ Installer.pkg/Contents/Archive.bom and grep for the appropriate entry, *guess which over-the-iChat solution I proposed to the user? Guess whether it worked?*
> 
> I agree that the generic "I repaired permissions, rebooted, repaired permissions and now my deceased mother has risen again" weenies are being stupid. But don't you DARE go writing the permissions fix off as a waste of time


----------



## hayesk (Mar 5, 2000)

MacDoc said:


> Yeah sure ...ignorance is bliss
> 
> ...
> 
> I concur....sometimes it works and it does no harm.


Actually, if you have any application that uses OpenBase in Leopard, it will cause harm. Repair permissions tried to reset openbase-owned files to system owned, causing the DBMS to stop serving its databases.

Your posted case could have been solved by a simple command. And anyone administering WebObjects should be familiar with the command.

File permissions don't spontaneously change - even through upgrades. Repair permissions is good when system files are moved to drives or folders where the permissions are not preserved. It is not a troubleshooting catch-all and people are treating it as such.

So sure, go ahead, repair permissions all you want. I have better things to do with my time.


----------



## GratuitousApplesauce (Jan 29, 2004)

biovizier said:


> There could be more than one cause for this. For one, there appears to be a bug in how permissions work in Leopard (i.e. they don't work as it is supposed to), affecting both the "Finder" and unix layer. Another possible issue is ACLs - in Leopard, users' "home" folders and most of their standard "top level" folders ("Desktop", "Documents", etc.) have the "group: everyone deny delete" rule that prevents deletion and moving (renaming counts as removing) of any items with that ACE. The problem is that the stupid new "Get Info" interface does not show this rule, yet allows a user to apply it to "enclosed items". So a user might make an intentional change to the permissions on eg. the "Music" folder to allow someone else access, then use "apply to enclosed items", not realizing that they are also transferring the ACLs at the same time. Then, since "Get Info" doesn't even display negative ACEs, the user can't get rid of it (or even know that they are there) without going to the command line.


First, many thanks for taking the time to give this advice biovizier. Much appreciated.

From what I'm reading it seems that there has been some unintended blowback from Apple trying to protect the top level folders in the users home folder. This seems like a good idea. When I was first using OS X I almost set in and started changing around those folders to a system of folders I had used under OS9 and earlier, until I just happened to read somewhere that this might not be a really good idea. But I'm sure that Applecare has lots of reports of people screwing up their systems by renaming their Applications folder to "My groovy warez" folder or something. 

I think in the case of my Music folder I may have altered all the contents from the Get Info window, applying permissions to all enclosed items, but I think I did that only after I ran into this "custom access" problem on some of the enclosed files, some that I had copied over from my older Mac using an external drive. Since I tried a number of different things, I'm not sure exactly of the sequence of events, but it certainly seems like the info provided in the Get Info window is definitely incomplete.

From what I can tell wherever these ACLs are present, the Get Info window will read under "Permissions & Sharing" "You have custom access" rather than any of the other things we have been used to seeing there.

In the case of my Documents folder, I'm pretty sure I didn't make any permission changes there but somehow these ACLs have shown up there. And within the folder it seems like they appear in a hit or miss fashion as well.

The bulk of the content in the Documents folder (which is pretty large, encompassing graphics, text documents and spreadsheets that I've created since 1994) was all moved over to my G5 from a backup recently. I got this new-to-me G5 PowerMac a bit more than a month ago, installed Leopard on its completely wiped drive and I copied my cloned backup of the HDD from my G4 PowerMac into a partition on one of the G5 internal HDDs. Then I copied the contents of the Documents folder from that backup into the Documents folder of my new Standard non-admin user account.

I wonder if there might be something else in place that causing these permission changes. Some background process run amok? I'm not discounting the possibility that I may have somehow inadvertently made these changes, but generally I'm pretty methodical about screwing around with stuff like permission changes.



biovizier said:


> The command 'chmod -R -a# 0...' just removes the first rule of the named item. If there is more than one rule, the former rule #1 becomes rule #0 (and so on) and the command would have to be repeated until all rules are gone. And as you noted, the command only acts on the named item but not on any contents if the item is a directory.


Hmmmm .... OK, I thought it might be working down a few levels but in a seemingly random fashion, but I could be mixed up. I must have misread the macosxhints post that I quoted because I thought that the author of it was saying that this command would propagate downwards.



biovizier said:


> Assuming you own all of the files, all ACLs on a folder and it's contents can be stripped using:
> 
> ```
> chmod -RN /path/to/folder
> ...


OK, just so that I'm clear that I understand this, I could use

```
chmod -RN /path/to/folder
```
 to take all the ACLs off my Music folder for instance as well as all the subfolders and files contained in it? Then I could go back and use

```
chmod +a "everyone deny delete" /path/to/folder
```
 to re-establish the ACL to just the Music folder without that going down the directory?

Thanks again, this is a big help.


----------



## biovizier (Dec 21, 2005)

> OK, just so that I'm clear that I understand this...


That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed.
Mac OS X Manual Page For chmod(1)

So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work:

```
chmod -RN ~/Music
chmod +a "everyone deny delete" ~/Music
```


----------



## GratuitousApplesauce (Jan 29, 2004)

biovizier said:


> That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed.
> Mac OS X Manual Page For chmod(1)
> 
> So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work:
> ...


Yep, that command seems to be working fine. I tried it on some lower levels and moved up to higher directories and it all seems to work. 

I also made an untitled folder within my home folder and filled it with some TextEdit files and sub-folders, to try out both commands on and they work exactly as advertised.

I've looked at the different man pages both within Terminal and elsewhere but I find that they are sometimes difficult as a non-geek to understand. I usually don't get too much useful info from them. I guess I need the UNIX for dummies version. 

Once again, many thanks. 

I'm going to be getting some feedback to Apple that they need to improve the handling of permissions on their Get Info windows so people like me can't so easily screw up our systems and then have to plunge into the chilly UNIX water to attempt to fix things.


----------



## biovizier (Dec 21, 2005)

GratuitousApplesauce said:


> I'm going to be getting some feedback to Apple that they need to improve the handling of permissions on their Get Info windows


That's great, and I hope more people do this. And I hope Apple listens because "Get Info" isn't really useful right now...

Getting back to the original question re permissions repair:


SINC said:


> When will Apple do something about this now useless and aggravating feature in Leopard?


Actually, the feature is better than it was before in one significant way. Recall that MOAB demonstrated that you could take a setuid executable, replace it with your own evil executable, and run "repair permissions" which would proceed to blindly "repair" the permissions of that file making the evil executable run with "root" privileges. No doubt in response to this embarrassment, a mechanism appears to have been introduced in "Leopard" that makes it possible to designate that a given setuid executable is to be checked (SHA-1 digest) agains a reference value, written to a database at the time the file is installed. However, one of the kinks in the system appears to be that when an update replaces or patches the original version of the SUID executable, the database storing the reference permissions and checksum information is not always updated with the new values (eg. the 10.5.1 stand-alone updater did, but the "patch" did not). So when "repair permissions" is run, it may recognize that the executable's sha1 doesn't match the one in the database, and throws up a warning message.

The database containing this information is "/Library/Receipts/db/a.receiptdb". I haven't been able to figure out how to get the system to force an update, or even how to get it to replace the database if it is removed. However, 'file' identifies the database as a "SQLite database (Version 3)", and Leopard conveniently has added '/usr/bin/sqlite3' to the default install. So if the messages bother you that much, it is possible to manually update individual entries yourself. Or you could just ignore the warnings until Apple smoothes out the bumps in the installation procedure. Ignore the messages, that is, unless you have reason to suspect something actually has illegitimately alterred the executables...


----------



## John F (Jan 25, 2008)

Permissions is one thing, but I have completely lost administrator access to my Macbook. None of several fixes so far has worked. It may be back to Tiger before the end of the weekend.


John F


----------



## jamesB (Jan 28, 2007)

MacDoc said:


> You'll notice that several utilities, SuperDuper, iDefrag, Onyx etc are not yet up to Leopard support.
> 
> There are clearly still some issues in handling the changes in the deep file structure.


Onyx claims to be good to go for Leopard wth their "Leopard Only" version.

jb.


----------



## bagelmaster (Mar 25, 2008)

*Thanks for the post*



biovizier said:


> That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed.
> Mac OS X Manual Page For chmod(1)
> 
> So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work:
> ...


After upgrading to Leopard could not rename any files or folders for my user account. Running that chmod command did the trick.


----------



## Benito (Nov 17, 2007)

I am still quite the newbie with Macs, what is Permissions and what does repairing it do for my Mac?


----------



## bagelmaster (Mar 25, 2008)

sorry, dude. I replied to the wrong post. confusing with all of the layers of quoting going one. Cheers.


----------



## hayesk (Mar 5, 2000)

Benito said:


> I am still quite the newbie with Macs, what is Permissions and what does repairing it do for my Mac?


Permission repair is something people do as a placebo instead of actual troubleshooting. For example, someone might say "I repaired permissions and restarted and my problem went way" when in actuality it was probably the restarting that made the issue go away.

There is a belief that permissions spontaneously change on their disks and must be "repaired" periodically. If permissions actually changed spontaneously, people would scream bloody murder to Apple for even thinking of releasing such a buggy operating system. It could never be used in a multi-user environment, and MacOS X Server would be a laughing stock.

Sometimes software does install with incorrect permissions or changes permissions of existing files that the installer needs. Sometimes Apple's installer changes permissions from the original, so the Repair Permissions looks like it is "fixing" something when either permission would have worked. It's possible, but rare, that this actually causes problems.

Basically, if you experience a problem that looks like it is related to the program not being able to read or write to a file, then it could be a permissions issue. Random crashes are usually not due to incorrect permissions.

In summary, I never repair permissions unless it is an actual permissions problem, and I've seen some instances of it actually causing problems.


----------



## GratuitousApplesauce (Jan 29, 2004)

Ahh, the permissions repair debate. It reminds me of the P-RAM zapping debate prior to OS X. "Zap the P-RAM seemed to be the all-purpose answer to anything that seemed wonky in OS9 and earlier. I just sit on the sidelines and watch people who know much more than me fight it out with each other. May the best geek win. 

From what I've read it seems like those who argue in favour of permissions repairing are saying that poorly written apps are what can screw with permissions, rather than them just spontaneously getting wonky. Could they be talking about MS and Adobe stuff or other apps that insist on a restart to install?

Anyway, since I don't know the answer to these questions, I'd like to know; does running a permissions repair actually endanger anything?

Benito, was asking "What are permissions." (Please anyone correct me if my wording isn't quite correct here) Permissions are little bits of data attached to files, folders and disks that control who owns and can access and interact with them and how they can do that, from reading only to full control of the file or disk. The user can set and change some permissions and "administrator" users can change most of them. If you don't know what they are, it's best to avoid messing with them if you don't have to.

Setting Permissions: Apple Support

Mac 101: Info from Apple geared towards Mac Newbies


----------



## MacDoc (Nov 3, 2001)

Except every maintenance tool does it as a default first step. For good reason.
It does no harm and once in a while helps as with all maintenance.

ONYX is the choice of many for weekly maintenance and yes it repairs permissions as well as the other scripts that your Mac would get around to if it was left on 24/7/365.


----------



## biovizier (Dec 21, 2005)

> does running a permissions repair actually endanger anything?


For the most part, "no" but theoretically, potentially, it could.

As MOAB showed, repairing permissions can be the final step in granting a local attacker access to your whole system (although even without repairing permissions, there are other routes an attacker could take). This probably isn't an issue any more in Leopard.

On the other hand, on a 10.5 system, if performed incorrectly, repairing permissions could endanger your security in another way. Specifically, if 10.5 was installed via the "upgrade" option, then repairing permissions while booted from a 10.4 or earlier disk (eg. the install disk that might have come with the computer) could cause a bunch of files to become setuid that shouldn't be (i.e. permissions set to 10.4 values). The most obvious symptom people have reported is that everything ends up running as "root" with the obvious security implications.

And "repair permissions" in 10.5 is so broken that it doesn't do its job - in this instance, it doesn't repair permissions.

But those issues aside, "repair permissions" is a tool that has a specific purpose and is useful within that context.


----------



## chas_m (Dec 2, 2007)

So if repairing permissions harms nothing and might possibly do some good -- and if it is by default Apple's first line of repair (as shown in both their support documents and by its placement in Disk Utility) -- and even third party companies do this before doing anything else ...

Why all the crazy-ass rants about it?

So what if YOU think it's a placebo? Since part of the mantra includes restarting, and the restarting is at least as likely to fix things as the permissions repair, there's no harm done and it makes people feel more in control of their own troubleshooting. If Apple said "sacrifice a chicken in a fork in the road under a full moon ... and restart your machine," I could understand if some folks gently reminded people that the killing a chicken part is just optional. 

And the same for repairing permissions. But the militant "it's complete folly, and you're a fool for thinking otherwise!" (and worse!) tack is just plain odd to me.

I'm trying to find the evil downside of repairing permissions that would explain this vitriol against it ... and I'm not finding it.

Save the froth for things I might try to do that could actually HARM my system, like changing permissions willy-nilly. Just MHO.


----------



## SINC (Feb 16, 2001)

chas_m said:


> Save the froth for things I might try to do that could actually HARM my system, like changing permissions willy-nilly. Just MHO.


While as many of you know, my Leopard experience has been less than perfect, after deleting iStat Pro, it is much better, but I can also say without doubt, that a simple "repair permissions" in Tiger took about a minute.

In Leopard, it still takes over eight minutes on my MBP 2.2 Ghz running Leopard.

That's progress?


----------



## chas_m (Dec 2, 2007)

SINC:

I'm very glad to hear you found the TRUE culprit behind your problems.

People do seem to have much longer permission-repair times in Leopard, including me (nothing like eight minutes, though -- maybe two at the most!). Of course, this could mean that we're not meant to be doing permissions repair any more often than "quite occasionally" now.


----------



## zlinger (Aug 28, 2007)

I had a 'repair permissions issue' occur recently after a system crash while I was deleting (or resizing? can't remember) a bootcamp partition. After a hard restart, I ran disk check and the errors appeared (maybe it is coincidently though), but I could not get it resolved.

Anyway, to make a long AppleCare phone call short, what I did was to boot from the Leopard CD and run disk utility from there. That fixed everything, and I have had no issues since.


----------

