Michael Kintzios schreef: <snip> >> Second, for general use (video viewing, game playing, etc) what you >> most likely want is the "users" (note the "s" at the end) option, >> which allows any user to mount/unmount the drive, as opposed to >> just one: >> >> from man mount: >> >> user Allow an ordinary user to mount the file system. The >> name of the mounting user is written to mtab so that he can unmount >> the file system again. This option implies the options noexec, >> nosuid, and nodev (unless overridden by subsequent options, as in >> the option line user,exec,dev,suid). >> >> users Allow every user to mount and unmount the file system. >> This option implies the options noexec, nosuid, and nodev (unless >> overridden by subsequent options, as in the option line >> users,exec,dev,suid). > > > So if I want a single user at-a-time to be able to mount the DVD > drives I just enter user? From memory I think I had concluded that > adding the uid was necessary for CDROMS and NTFS/VFAT fs partitions, > otherwise it was asking for fs type, or was coming up with "only root > can do that" type of errors. Need to try this again and make some > notes. > > The problems that I have are probably two-fold. The generic one is > that I am not sure I have the correct mount options in /etc/fstab and > that I created the /mnt/cdrw, /mnt/cdrom1 etc. mountpoints with the > correct access rights. What are the default mount options and > /mnt/mountpoints access rights for DVD writer and DVDROM? Ditto for > NTFS?
Sorry, I don't use NTFS, and I only have one user (me)-- and I don't use /mnt/cdrom or /mnt/cdrw (or /mnt/ anything other than the self-created /mnt/iso for mounting loopback images)-- my DVD is mounted to /media/(cdrecorder) by udev (afaik it's udev that does it). I take it you don't use udev? Or are you just under the impression that you have to have /mnt/something (I had this problem for the first bit after I switched)? In general use, /mnt./blah is kinda deprecated. However, I do know that enabling writing to NTFS partitions in the kernel is not recommended, unless you meet very specific criteria (as the kernel driver can only overwrite a file of the exact same size to such a partition, making editing pre-existing files pretty much impossible; no idea about creating a new file). UID/GID is (kinda) necessary for VFAT partitions, only to deal with the possible ownership issues; if you specify the UID/GID of the expected owner, that UID/GID can/will have write privileges to the partition (automatically if UID, when specified if GID), which is useful for shared partitions across multiple distros or OSes and sometimes for multiple users on the same OS. But you may not need any given partition to have write privileges. If, for example, the partition is only full of music files that only need read privileges to play, which you'll almost always have when mounting a partition. But if you wanted to edit the ID2/3 tags of the music files, you would need write privileges. But how many users on your system are actually likely to be editing such tags-- given that said users could also destroy said files with a Windows virus if the virus targeted MP3s and the user had write privileges to the partition containing them? As the admin, you are responsible for knowing what accesses your users actually need, and balancing that against the dangers of giving them such access. It really depends on what your specific setup needs, which we cannot know. > > The specific one is that I tried to delete a folder from a > re-writable CD: a)while I was browsing it in konqueror and b)using > k3b, but it couldn't do it. I'll try again when I get home to see if > it behaves as expected after I ensure that it has not been mounted. Um, hello, this is not WindowsXP. We do not packet-write (that means treat a CD as if it was a floppy and write to it directly from the file manager). You can (kinda) do this, if your kernel is set up to enable packet-writing, but honestly that functionality is quite unstable and I wouldn't use it even if I did like packet writing (which I do not and never have in the some 6 to 7 years since it was introduced). Basically what would need to happen in the real (Linux) world, without packet writing, is that a CD burning program would have to create a temp ISO of the files on the CDRW (which afaik it would have to be) without the folder that you intended to delete, erase the current contents of the CDRW and then rewrite the CDRW with the new ISO (which would essentially delete the folder). But I could be wrong, as I don't use -RW media anymore (and this is one of the reasons why). In any case, I'm not completely sure that your expectations are reasonable for the environment. Certainly expecting Konq to delete a folder on a CD is unlikely to happen (because the device must be mounted for Konq to see it, and the device is not going to be mounted read-write under any circumstances; this is why, afaik, the kernel only marks the device as writeable using the ide-cd driver and then CD burning programs use raw device access to access and write to it). I have no idea whether Konq supports packet writing if enabled in the kernel, but I would seriously doubt that it does. K3b would likely do the whole "create a temp ISO without the proposed-to-delete folder, erase, and reburn" thing, but it's possible that you don't have K3b properly set up to do this (do you have a location set for the creation of temporary ISO files, for example? Is there enough space there for the temp file?). As I said, this is not something I do, not using -RW media, but as far as I can see it's a whole process. What errors precisely are you getting, so we could see where in the process it may be failing? HTH, Holly -- gentoo-user@gentoo.org mailing list
