Bug 429744 - autofs responds with "No such file or directory" and does not mount
autofs responds with "No such file or directory" and does not mount
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-22 15:55 EST by Michal Jaegermann
Modified: 2008-01-25 12:44 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-25 12:44:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-01-22 15:55:07 EST
Description of problem:

To eliminate any nautilus/gnome-mount interference I am running
now on runlevel 3.

In /etc/auto.master I have a line

/cd     /etc/auto.media

and in /etc/auto.media this:

cdrom   -fstype=auto,ro,nosuid,nodev,user=$USER         :/dev/cdrom

With autofs stopped one can find a directory /cd/cdrom.

After 'service autofs start' /cd/ is empty and 'ls /cd/cdrom'
comes back with

ls: cannot access /cd/cdrom: No such file or directory

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.

A similar access over NFS to subdirectories of /net exported by
other hosts is still operational.

Version-Release number of selected component (if applicable):
autofs-5.0.3-3

How reproducible:
every time
Comment 1 Michal Jaegermann 2008-01-22 17:09:18 EST
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!
Comment 2 Ian Kent 2008-01-22 23:17:07 EST
(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
Comment 3 Michal Jaegermann 2008-01-23 13:28:33 EST
> 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.
Comment 4 Ian Kent 2008-01-24 11:45:13 EST
(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
Comment 5 Michal Jaegermann 2008-01-24 12:52:26 EST
> 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.
Comment 6 Ian Kent 2008-01-24 23:07:25 EST
(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
Comment 7 Michal Jaegermann 2008-01-25 12:44:26 EST
> 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.


Note You need to log in before you can comment on or make changes to this bug.