OK... I was able to move some Ogg files onto a Cowon D2 a few days ago. Now I want to delete them -- so I can reorganize things by artist and album/CD -- and I cannot. (I'm trying to pull together a bunch of music and pre-install my daughter's favorite music on the D2 for Christmas.) A "mount" command says the device is mounted as a vfat filesystem on /media/COWON with attributes "rw,nosuid,nodev". When I attempt to delete the music files that I created -- under the "music" folder in subdirectories like "band/album/" I get the error:
This used to work but I cannot for the life of me figure out why "mount" thinks I have write access but I cannot write files or remove them. Everything on the D2 looks like it's owned by root:root and has permissions 755 so I ought to be able to about anything I can think of to the stuff I downloaded onto the D2. But no luck; the files are still there.

Does it make sense to even try to organize the music into subdirectories or would it be better to let the ID3 tags do that?

This is all taking place on an SUSE 10.3 system (which has always basically been a major pain in the ass when it comes to removable USB devices) so perhaps thats a lot of the problem. The firmware on the D2 is 2.54. I can try it on an 11.0 system tomorrow to see if that makes a difference.

Any ideas what's going on here to prevent my attempts to clean out the old music files? At the moment, I'm having second thoughts about giving the Cowon as a gift if it's going to be this difficult to change the music on the thing.

Update: I disconnected the D2, reconnected it, and was able to delete an empty "band" subdirectory. And I was able to remove a single file from another group's subdirectory. But only one; the rest are somehow write protected. Still. (Maybe a few mount umount/mounts will do the trick. My daughter's gonna just love that. )


TIA...

--
Rick

Use root privileges to delete files or remount by adding umask=000 to the mount options.

I was doing all the file manipulation as root. (10.3, 'member? Non-privved accounts and removable media don't work worth a darn on 10.3 so I'm well used to using root for anything involving CDs of USB devices. I recall reading of a patch that was supposed to fix that but I couldn't relocate the post that mentioned it.)

Anyhow... most of my woes seem to have been caused by plugging the D2's USB cable into a hub. Moving the cable to a port on the back of the computer solved all the flaky "you can only delete a single file at a time until you umount and mount again" problems I was seeing.

With luck I'll have some time to finish my 11.0 testing and can embark on a series of upgrades throughout the house. I suspect that'll help out a lot on the problems we've been having with removable media. No time for that now. At least I have a workaround to I can finish preloading my daughter's player. Then it'll be on to the upgrades.

later...

--
Rick

I am not sure what you are saying. Also I am thinking you did not understand what I previously posted.

If the storage device Cowon D2 is formatted as FAT, you have to set all files with a certain file and directory permissions when trying to mount it in Linux. FAT does not use UNIX permissions for its directories and files, so you have to use the umask option. I assume SUSE uses dbus and/or hal to automatically mount the device. You may have to change how it mounts FAT partitions or set special mount commands that will mount the correct partition for the Cowon device.

Assuming the Cowon D2 comes up as /dev/sda and the partition that you want to mount is /dev/sda1 and the directory /mnt/cowon is where you want to be used for /dev/sda1. The following command could be used.

mount -t vfat -o rw,umask=000 /dev/sda1 /mnt/cowon

The umask is just a bit mask. The value 000 means 777. A umask value of 222 will be 555.

I think USB active hubs should work better than passive hubs.

IMHO, SUSE is very proprietary, so any how to that you have read will make you have to think into SUSE commands and where certain files are located. I suggest try a different distribution like Sabayon or setup sudo to limit the use of mount and other utilities.

If you use kde, and use automounting, you can right click on the icon for the device, select properties and change the way the device is mounted.
Make sure the Mount As User checkbox is selected. I'm sure that Gnome has the same or similar options. I don't use gnome so I don't know for sure.

If you create an fstab entry however, the HAL system won't automount it. If you want to manually mount the device instead, you can use the "uid=" and "gid=" mount options to change the ownership and default group for the mounted filesystem.
Please note that 555 permissions allow reading and executing but not writing. That could be why you aren't able to delete the files.

If there is a problem with the filesystem, it may be mounted readonly to prevent further damage. If that is the case, there should be a message telling you in /var/log/messages. Downloading all of the files from the device and using the devices functions to reformat the flash inside the device may be the best action in that case.

If the automounting functions don't seem to be working at all, a possibility is that you are booting with the noacpi boot option. This will prevent dbusd and hald from running which are the services that are key components of the automounting system.

Good Luck!

Quite possibly...

It's recognized by SUSE as a VFAT device.
I never needed to do this with versions of SUSE prior to 10.3. 10.3 is broken in this respect. I have other Older) SUSE systems that immediately recognize USB storage device when they're plugged in and I can move files back and forth as a non-root user. It's just 10.3 that's fouled up. (Hence my impending move to 11.0 with hopes that things will improve.)

When SUSE automounts the Cowon, "df" shows and "mount" shows neither of which look any different (other than the device name) than I recall seeing on the older 10.x versions. Taking the hub out of the picture allowed complete access to add or delete files without any trouble.

If what you mean is that the hub has its own power supply, I agree. I seem to remember trying a borrowed, non-powered hub some time back before switching to the current one (or was that at work; can't recall and not that important). The borrowed one was a turkey. But... even the new hub had problems under SUSE 10.2. Things improved under 10.3 -- the scanner now works through the hub; it didn't before -- but obviously there are certain devices that aren't supported quite right yet.

No more so than, say, Red Hat (which is what I had standardized on prior to switching to SUSE).
Yes. I'll switch to a distribution that most folks haven't heard of before. I think I'll pass on that one. (And with our slow DSL line here at home, if it ain't available through Cheapbytes, it ain't gonna get loaded on any of our systems.) And how would limiting the use of mount help me? You've puzzled me with that.

Later...

--
Rick

It does. As a non-root user, though, I'm prevented from making any changes to the properties. I can try this as root to see if such an option even appears. (It doesn't when I'm logged in as a non-root user and right-click on the desktop icon for the Cowon.)

It's being automouted by the OS.See the output of "mount" quoted in another reply. The device is being mounted read/write. The files are owned by root:root, the permissions are 755, and I was attempting to alter the Cowon's contents as root.

There were some odd-looking messages that I missed earlier. The device was being detected and noted that write protect was "off" but later there was a weird message about an unknown partition table for a SCSI device other than the one that was actually mounted. (It wasn't about any other SCSI device on the system, either.) Since I bypassed the hub that I had been plugging it into, those messages have no longer been appearing in /var/log/messages.

The boot command line from /proc/cmdline does not show that the "noacpi" option is being used. There are daemons running for both dbus and hal.

Later...

--
Rick

I suggest you re-read my previous post. It explains about FAT and what you need to do in order to write to that file system. vfat is just a file system module for Linux to handle FAT16 and FAT32.

The following does not mean that it has read-write permissions.

/dev/sdf on /media/COWON type vfat (rw,nosuid,nodev)

The following means that has read-write permissions.

/dev/sdf on /media/COWON type vfat (rw,umask=000,nosuid,nodev)

Using dbus and hal for automounting is not perfect. I recommend manually mount the storage device. It is easier. If you insist using automounting, you have to edit dbus and hal scripts to do things the way it should.

Try buying from easylinuxcds.com. If your DSL is that slow, then you need to look at other ISP in your area.

And yet here I am, happily moving files back and forth to the device mounted with those exact mount characteristics. Must be magic or the phase of the moon.

Look... I solved the original problem (through eliminating possible causes at the time even though I had no good reason to suspect the hub would wind up being the problem) so we don't really need to pursue all the manual mounting, change your distribution, and your ISP solutions that are being offered up. For now, things are working. When I starting working more with 11.0 (or the new 11.1) things might get more interesting than they are right now. Issue closed.