On Mon, 23 Dec 2013 20:28:34 -0800
John Jason Jordan <[email protected]> wrote:

============%<------ SNIP! ------>%============

> Then I did sudo chmod 777 -R /media, which produced
> error messages:
> 
>       chmod: changing permissions of /media/jjj/Devil-Bonobo:
>       Operation not permitted
> 
> And so on for everything in /media.
> 
> Using Thunar I checked on Properties for /media/jjj and it said that
> it was owned by root:root. I assume that it was owned by root because
> I had to use sudo to mount it. But that doesn't make sense. We always
> have to use sudo to mount things, but the regular user can still see
> them after they are mounted. And how is it that root cannot change
> permissions?

I ran across this once.  Thunar won't help here, nor any of the
GUI file managers.  You'll need to do an lsattr(8) of jjj whilst
in /media.  You should get something like this:

-------------e-- ./backtrace.txt
-------------e-- ./ligature-test.mom
-------------e-- ./compose_key_combos.txt

If there is an "i" in the first column, you have an "immutable"
file.  You'll have to use chattr(1) to change the attribute.
"chattr -i /media/jjj" SHOULD do what you need -- the "-i" means
"remove the i attribute", rather than "option i".

> I wonder if it is possible to mount a filesystem at more than one
> place simultaneously. Movies has to stay mounted at /media/jjj because
> Ktorrent is seeding torrent data located there. Changing data
> locations in Ktorrent is a major pain (I've had to do it). But if I
> could mount movies simultaneously in ~/, then the ~/ share should
> suffice, since it is working.

Yeeesss, but I'd try the lsattr(1)/chattr(1) method before doing
that.  Look up Bind and Loop mounts in the mount(8) man page.  I'm
leery of doing something like this for fear that, with one worng
keystroke, I could hose an entire filesystem.

BTW, the question popped up earlier about an fstab entry for
removable drives.  Here's what I use for the drive holding my
music:

  # MusicData has my music collection in it.
  UUID=<fs-uuid>  /srv/musicdata  ext4  noauto,users  0  0

This allows me to mount/umount the drive as myself, rather than root.
Since the last two fields (0 0) are zeros, you could simply leave them
off.  The zero in the fifth field tells the system not to use dump(8)
to back up that fs.  (Does anyone still use dump?)  The sixth field
tells the system when and if to run fsck at boot time.  This one MUST
be zero, which tells the system to skip this fs.  Otherwise, if the
drive is not connected you get dropped into an emergency shell in the
middle of boot-up.  Such a lovely surprise.  Ask me how I know.

Anyway, I hope this helps.

--Dale

--
I recall hearing that highly-classified data must be destroyed by
physically shredding the medium.  Yes, throw your disk drive in
the shredder!  (Just imagine the class of machinery required to
digest an RA81 HDA.)  -- Mark Wood on linux-kernel
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug

Reply via email to