It turns out that my iTunes ID3-editing problem was indeed permissions-related, thanks to NFS brain damage.
(Warning: *so* boring. Zzzzz…)
NFS expects the numeric user and group ids to match up between any systems exporting and using shares, but when I set up the iBook and it created a user account for me, it automatically assigned a number that didn’t match the file server (it had no way of knowing or expecting that, of course) and there doesn’t appear to be a way to remap ids in the NFS server. Since it’s now months later and I’ve done a bunch of stuff with this user account, I’m hesitant to start mucking about and trying to change the numeric id of the account lest I in my Mac n00bishness break some internal dependency. There is a workaround of sorts, though; by using the all_squash, anonuid, and anongid options together on the export, the NFS server will perform all operations on the share as a specific user. Only one user for the whole share, but since I’m the only user on the network anyway, that’s fine.
That’s not good enough for iTunes though. The problem is that although you can perform operations as a user who has access to the files, the files still appear with the mismatched uids and gids. If you were to just look at the uids, gids, and permission bits, and *theorize* about whether you were allowed to, say, write to a file, you’d get the answer ‘no’ even though it really would work if you were to try it. iTunes appears to be doing this theorizing and not even bothering to let you edit the ID3 fields if it thinks it won’t be allowed to rewrite the tags.
Another possible workaround is to make an ‘nfsusers’ group on the iBook with a gid matching the gid of the files, add myself to the group, and make all the files and directories group writable, and that does appear to work. However, I don’t like having to remember special-case security policies for different directory trees, and I wanted to give one more alternative a chance: Samba.
Setting up Samba took a bit of experimentation, but was pretty painless overall, and once it was done I could map the share and see all of the files with visible permissions that would let me access the files, and iTunes was happy and I can easily map them from the XP box too. Unfortunately that leads to Samba’s form of brain damage, exactly opposite of NFS: since you’re not really seeing the true underlying permissions, you can appear to have the ability to do things to files that will fail if you actually try them. And the volume on the iBook vanishes as soon as the server connection is broken for any reason. And reconnecting the volume always asks me to reauthenticate even after putting it on the keychain. Oh well, it still works well enough, and there are probably solutions to those annoyances if I dig around a bit.
Then just for kicks I decided to try and use Samba to make the Linux box a primary domain controller and spent the next few hours fighting with group mappings and roaming profiles and botched user setting exports, but that’s a different story…
It’s funny, y’know…. For the Mac, I use DAVE for Samba stuff (holy options, Batman!); and since there are absolutely *no* Windows machines in this house anymore (Mom’s PC went tits-up, so I gave her my iMac), everything is smooth.
I mean, SMB is a Windows-borne initiative, and yet when you remove Windows from the picture, it actually all works. It didn’t, when there was still a WinPC on this LAN. Another bit of irrefutable proof to support the revolution! ;-)
My last remaining Linux box does all the Windows-like server shit, and as a result, all the machines here play perfectly nice with each other.
DAVE might make a good chunk of your other problems (except the roaming profile stuff — I’ve never had call or need to work with those outside of a corporate culture) go away, if you’re interested.
On a slightly related note, I’m kinda surprised that you’re using NFS at all, considering its’ fame as a giant security hole. ;-)