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
