Bug 429744

Sigh!  It appears that these are not autofs changes.  While
quite recently I had to use 'user=$USER' in mount options,
while 'uid=$UID' was ignored, now the first form rejected for
a change and resulting error is printed as "No such file or
directory".

While I can change /etc/auto.media to read

cdrom   -fstype=auto,ro,nosuid,nodev,uid=$UID           :/dev/cdrom

this has that unfortunate effect that after automounting from
a non-root account I see in 'mount' output:
/dev/sr0 on /cd/cdrom type iso9660 (ro,nosuid,nodev,uid=400)
and attempts to unmout that and/or eject end up with

only root can unmount /dev/cdrom from /cd/cdrom

regardless of options in /etc/fstab, or 

Error: mount point /cd/cdrom is not below /media/

if "/dev/cdrom" line in /etc/fstab is skipped.  That makes
autofs for a local media and a non-root user practically useless.
Any ideas how to unbreak that?

Moreover, fairly recently yet it possible with autofs to work around
hald/gnome-mount (heavily censored) handling of CDs on a graphic
desktop.  Apparently now autofs here always "looses".  Bummer!

(In reply to comment #0)
> 
> but not before one can see and hear an access to a media in a drive.
> The above used to work in the past, and disks were mounted.
> I am not sure when this was broken. Backing off to 5.0.3-2 does
> not help nor booting with an older kernel.

When in the past?
With autofs?

Ian

> When in the past?
Oh, a week ago or ten day ago.  Something in that range.

Recently nautilus was quite broken so I did not try that.
After other things got updated, and nautiluse started to work
again, my older setup fall apart.  I think that I explained 
that in comment #1 and what changes I had to make, which is
not really autofs, but after all that I had to use 'root' to
unmount autofs mounted CDs.  That is a serious obstacle.

> With autofs?

Yes.  I was using autofs to work around hald/gnome-mount
contortions with CDs.  Highly regrettably this does not 
seem to work anymore.

(In reply to comment #3)
> > When in the past?
> Oh, a week ago or ten day ago.  Something in that range.

Strange as the syntax you give doesn't work on F7 or F8.

Can you give an example that actually does work as I can't
get this to work?

There must be more to what you've done in the past than
just the mount options that you gave here, we need to work
out what that is if we are to get anywhere with this.

Ian

> Strange as the syntax you give doesn't work on F7 or F8.

We are talking about rawhide here.

I tried to follow an advice given in
https://bugzilla.redhat.com/show_bug.cgi?id=424491#c3
At that time I could not anywhere with using "uid=$UID"
but "user=$USER" did work.  Apparently this time is the
other way around.  As I noted in comment #1 it looks like
that changes elsewhere, and not in autofs, affect results.

Closer look seems to show that there is a race, in what I
was trying to achieve, between autofs and hald/gnome-mount
(or whatever mechanism is used in all of this) and outcomes
depend on what will grab that cd media first.

> Can you give an example that actually does work ...

cdrom   -fstype=auto,ro,nosuid,nodev,uid=$UID           :/dev/cdrom

definitely does work.  In an output of 'mount' I can see right
now a line:

/dev/sr0 on /cd/cdrom type iso9660 (ro,nosuid,nodev,uid=400)

'iso9660' could be 'hfsplus' equally well and I do not have
any 'udf' formatted CDs on hand.  The same disk mounted via
desktop mechanisms shows '(ro,noexec,nosuid,nodev,user=michal)'
in mount options.

Unmounting the above could be "iffy".  I have seen various error
messages in a response.  Oh, well ...  It appears that hacking
hal policy files may have better effects but it would be nice
to have something, short of 'sudo', if only a text console is
available.

(In reply to comment #5)
> > Strange as the syntax you give doesn't work on F7 or F8.
> 
> We are talking about rawhide here.

I was suggesting that, given you're description, this
never worked.

> 
> I tried to follow an advice given in
> https://bugzilla.redhat.com/show_bug.cgi?id=424491#c3
> At that time I could not anywhere with using "uid=$UID"
> but "user=$USER" did work.  Apparently this time is the
> other way around.  As I noted in comment #1 it looks like
> that changes elsewhere, and not in autofs, affect results.

The "user" option and it's variations are valid in fstab
mount entries only.

This has been a long standing difficulty with autofs and
I still don't know of a way to resolve it.

> 
> Closer look seems to show that there is a race, in what I
> was trying to achieve, between autofs and hald/gnome-mount
> (or whatever mechanism is used in all of this) and outcomes
> depend on what will grab that cd media first.
> 
> > Can you give an example that actually does work ...
> 
> cdrom   -fstype=auto,ro,nosuid,nodev,uid=$UID           :/dev/cdrom
> 
> definitely does work.  In an output of 'mount' I can see right
> now a line:
> 
> /dev/sr0 on /cd/cdrom type iso9660 (ro,nosuid,nodev,uid=400)
> 
> 'iso9660' could be 'hfsplus' equally well and I do not have
> any 'udf' formatted CDs on hand.  The same disk mounted via
> desktop mechanisms shows '(ro,noexec,nosuid,nodev,user=michal)'
> in mount options.

But autofs should be able umount this at expire time.
It should work fine.

Fact is, if you start manually umounting filesystems that
autofs is managing the result is undefined. I've tried to
make autofs resilient to this and in many cases it will
continue to function OK but you can't rely on it. Basically,
manually umounting autofs managed filesystems isn't supported.

The interference of GUI functions such as a "umount" option in
a drop down menu could easily cause unusual problems.

Ian

> But autofs should be able umount this at expire time.

If you work with something then waiting for an expire time
could be really annoying; unless you set that to be very short
but this has other disadvantages.

> Fact is, if you start manually umounting filesystems that
> autofs is managing the result is undefined.

That makes its usefulness somewhat limited.  Oh, well, some
other ways to overcome limitations are then needed.