I dug through this forum in hopes to get my ipod running. I got it, and everything is working fine. Does anyone know how to add the command "Safely Remove" to the menu that pops up when I right click the sda2 icon in X? I've been running the eject command from the "run command" dialogue and that works fine. I know i'm being picky, this is more of a learning experience. Here is the line from my fstab file, maybe the issue lies here.
also, I get an error during my shudown script that says something like "warning! no last line in fstab file" (not word for word!) Maybe thats another clue.

I'll assume you are using KDE...

An easy way for you to 'Safely remove' your IPOD is to create a desktop link to it. To do this, right click, new, link to device. In the device tab, make sure you have switched it to /dev/sda2 (your IPOD). Then, all you have to do when you want to mount it is click your shortcut, and right click it and press 'Unmount' to safely remove it.

About the 'No final line.'. I used to get this message to. Just add a blank line at the end of your /etc/fstab file.

in a terminal, you can use umount /dev/sda2. i use rox filer, and that offers the ability to unmount drives such as flash drives and such...don't know if thats something you're interested in.

Yeah, use that command. It works great for my flash drive, but my ipod requires a "safely remove" command such as eject.

Under KDE the eject command works fine logged on as root, but when i try to eject from another user, it wont do it. I've been typing the eject command the "run command" box. Now as a regular user I have to open the terminal, su, then eject. This works fine, but is there a way to grant that right to my users?

Install Linux on it, maybe that requirement will go away.

Joking.

Change your 'users' to 'user' in /etc/fstab.

All that eject does is run 'unmount' and then try to open the door of the device in question. Of course your iPod has no door...
However, since USB transfers are cached, sometimes unmounting the device will take awhile -until everything is written to the device. So, if you create a shortcut for the unmount command, you should have it run in an xterm so you can see the output and know for sure that it's 'safe' to remove.

unmounting is no problem. The bottom line is that after a standard umount /dev/sda2, the ipod itself still says "Do Not Disconnect." As root, running the eject command removes that message from the ipod. Here is a bit of info that might help. My system labels the icon "Hard Disk (sda2)."

I believe the eject command also syncs all data transfers. Handy, since USB transfers are usually done async.

Regardless, the eject command is needed to get the "Do Not Disconnect" message to go away on the iPod.

A simple method for doing this as a user is to make eject SUID. This has security implications, so doi so at your own risk.

Another method would be to configure custom UDEV rules so that the iPod (the whole thing, not just the data partition) has the proper permissions to allow users to eject it.

I use the first method, but the second is probably a better choice. I just haven't bothered with coming up with the rule.

Awesome. where do i change udev rules?

Create a file for custom udev rules:

/etc/udev/rules.d/local.rules

Changing eject to SUID is easier (if you don't want to bother creating a rule), though:

In an attempt to learn what I'm doing rather than just following code I pick up from this site, I have to ask what exactly that line means (chmod +s). Could you break it down for me?

A great way to learn what it means is:

It's a fairly straight forward read.

To sum it up, "chmod" is the "change mode" AKA "change permissions" command. The "+" means "add the following permissions". The "s" means "set user ID" AKA "make it SUID". The final part, "/usr/bin/eject" is the file/program that is being changed.

If you don't know what SUID means, it means that after running this command, any time /usr/bin/eject is run, it is run as root. That is why the permission error goes away. That is also why this can be viewed as a security hazard. If running a program SUID, someone may be able to exploit a flaw in the program to spawn a new shell. That shell would of course be a root shell.

Using UDEV to set appropriate permissions would avoid this possible issue. I am pretty sure that would be all that's needed, though it depends on your system. If you are running HAL, you may also need to tweak an .fdi file.

Myself, I just use the SUID solution.

Bonus tip: The eject command included with Slackware tends to throw an error (deprecated SCSI I/O control). This can be solved by compiling the newest eject from source and copying it over the stock version.

The only issue that I have had so far is that sometimes, after extended writes to the iPod, the eject will still fail. Not sure if this is a sync issue or what. In my experience, though, this means that FAT formatted iPods are better suited to Linux that HFS+ formatted iPods. I say this because there are more correction tools for FAT. If the HFS+ filesystem becomes corrupt due to early unplugging, you end up only being able to mount the iPod read-only.

Somewhat related to this is the little light on the usb thumb drive. Does anybody here know how to turn those off? eject doesn't work.