I'm using an old iBook G4 (PowerPC) running Tiger to serve iTunes to the house. For the past week or so, the mac boots fine, and then sometime during the day starts generating

An unexpected error occurred (error code -50).

errors when iTunes attempts to save its library file.

Checking reveals that the boot drive (main drive, in the laptop) behaves as if it is write-protected - I get the same error code when I attempt to create a folder on the desktop, for instance. If I attempt to create files via the terminal, e.g. via ls > foo.txt I get an "invalid argument" error.

I've set the iBook to run in Target Disk Mode and run Disk Utility to repair the disk (from a Macbook running Snow Leopard) and get "The volume appears to be ok".

I don't have the option in Disk Utility to Repair Permissions in Target Disk Mode. When I ran Repair Permissions on the iBook itself, it came back with no errors, no permissions corrected, but did not in fact fix the problem.

Rebooting always solve the problem - for the next 5-10 hours or so.

Would Disk Warrior help, or some other software fix, or is it time to buy a new drive? (And, in any case, what's going wrong?)


3 Answers 3


Error 50 is a generic - iTunes has failed to write a file and the article listing specific store errors (expand the section on Specific Conditions and Alert Messages to reveal -50 in that section) deals with the usual problems where the store is failing or the network is failing.

If the error is bubbling up from the filesystem (or you get the error from Finder), then it's often an "illegal" character in the file or folder name. Look to remove or rename files with emoji, unicode characters or more mundane characters like : & or /

In your case, it's very likely the drive is the cause. You can and should look in the console app to see what other errors happen around that time. Look for I/O errors - disk0 - or just run disk utility and have it verify / repair the catalog file. This will confirm the guess that the drive is failing and the errors are not some software problem.

You could export the current library xml to the desktop and start over with a brand new iTunes library file just to rule out corruption in that file, but then you would have two problems at the same time - terminal unable to write a file and iTunes unable to write a file. Occam's razor (and my experience) says it's the filesystem/drive - not two identical software problems.

Spinning hard drives do track the sectors where a bad write has happened and try to keep track of them so the system won't notice files not vein written, but as a drive ages (or if this mechanism fails) you will get unrecoverable errors more and more.

Also - it's often hard to tell if the catalog structure is bad (which Disk Warrior, Drive Genius and plain old erase in Disk Utility attempt to fix assuming the drive works properly). But if the underlying hardware is failing, you'll need to move to a new drive.

I would just make another backup and zero the drive and look for errors during the zero / reinstall. If the errors persist, it's time for a new drive once the pain of reboots is more than the cost of a new part costs.

In your specific case of an old PPC machine where repair is invasive and the cables likely to be brittle, I would just re-install the OS onto an inexpensive and many GB external drive and run the mac from a cheap USB drive (most iBooks will boot from USB, but not all will) - leaving the potentially failing internal drive sitting unused, unmounted and spun down. It's rare for a failed drive to take down the machine so you can just leave it alone for minimal cost if you can tolerate the iBook running on an external drive.

  • 1
    Agree on the Occam Razor inference - other programs that need to write files to the boot disk complain as well. Also wondering why rebooting cures it, temporarily? Mar 13, 2012 at 19:14
  • It would be interesting to graph how long after a reboot the system was clean. Do you shut down or just an on-the-fly restart?
    – bmike
    Mar 13, 2012 at 19:19
  • On the fly restart. Mar 13, 2012 at 20:02
  • Someone reporting what seems like a similar problem, on an external drive [forums.plexapp.com/index.php/topic/… Mar 13, 2012 at 22:08
  • Hmm the apple doc is for "Mac OS 9 and earlier" so I don't think it is relevant
    – mmmmmm
    Apr 20, 2013 at 8:40

Error -50 in relation to Mac OS X or OS X

The error:

  • relates to the file system
  • may occur with a good file system on a good drive.


… Tiger to serve iTunes …

That's open to interpretation.

Considering the range of situations – not limited to iTunes – in which issues occur, I imagine that:

  • with Tiger on the iBook G4, you use the Sharing pane of System Preferences to share a folder
  • with Snow Leopard on the MacBook, you prefer iTunes to write its library to part of that shared folder.

If so, then you should take care with:

  • the numeric IDs of all users of iTunes
  • at the iBook, the ID of the user where you find issues with the home directory
  • at the iBook, the permissions of all folders and subfolders that you wish to be writeable by remote users of iTunes.

Hint: the ability of Disk Utility to verify permissions does not extend to situations such as this.

iTunes aside, the question makes me wonder whether ownership is as it should be on the iBook. An issue might arise if, say, a home directory was copied from one Mac to another without attention to numeric IDs of users.


At the iBook, with Terminal, command:

ls -n ~

ls -dn ~

ls -dn ~/Desktop

For each of the three outputs: in the third column, note the numeric ID of the owner.


dscl . -list /Users UniqueID

Does the numeric ID match?

And so on … consider the numeric ID of each remote user of iTunes.


dscl(1) OS X Manual Page

  • in this case, the version of the page for Mac OS X version 10.4-intel may be equally good for Tiger on PowerPC.

It's a bug in fseventsd. For an external drive or secondary (non-boot hard drive), the fix is easy. Drop into the command line and sudo remove the .fseventsd of the offending drive. To do it, you'll need to run an rm -Rf which is an extremely dangerous method of deleting something if you do not know what you are doing, as it will delete with extreme prejudice.

e.g.: cd into the drive cd /Volumes/(drive name), then run: sudo rm -Rf .fseventsd

It will delete the fseventsd cache and you will be good to go. Unmount the disk and remount it and it will work immediately.

There is an alternative workaround where you can remove that directory, then create your own .fseventsd directory, which you will put inside a file called no_log

That will stop the system logging events to the drive.

You can try other fixes such as writing to defaults various instructions but this is the simple fix to get you unstuck.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .