Bug 424491
| Summary: | autofs fails to mount cd (regress) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | autofs | Assignee: | Ian Kent <ikent> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | ikent, jmoyer |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-12-14 03:47:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
(In reply to comment #0) > Starting automount with options '-v -d' in /etc/sysconfig/autofs > does not make me much wiser. I see > > automount[3029]: attempting to mount entry /cd/cdrom > automount[3029]: lookup_mount: lookup(program): looking up cdrom > automount[3029]: lookup(program): lookup for cdrom failed This would indicate that somehow /etc/auto.cd has the executable mode set and since it's not a program (or script) it returns nothing to autofs so the mount fails. Please try removing execute mode from the map and try again. Ian You are correct about executable mode set. In attempts to get this working I set this on /etc/auto.cd and forgot about it. But all of this it does look as some fight between autofs and whatever mechanisms are used by a gnome session to handle removable media. No idea why I had troubles before I changed that execute bit but right now if I will do 'ls /cd/cdrom' with a media in a drive then this gets mounted but 'user' option is apparently dropped. Trying to use "Eject" menu entry on a corresponding desktop icon now brings me an alert that I have no priviledges for that operation and after that CD is ejected. :-) Whatever. I can live with results even if weird things happen from time to time. (In reply to comment #2) > But all of this it does look as some fight between autofs > and whatever mechanisms are used by a gnome session to handle > removable media. No idea why I had troubles before I changed > that execute bit but right now if I will do 'ls /cd/cdrom' > with a media in a drive then this gets mounted but 'user' > option is apparently dropped. Trying to use "Eject" menu entry > on a corresponding desktop icon now brings me an alert that > I have no priviledges for that operation and after that CD > is ejected. :-) Whatever. I can live with results even if > weird things happen from time to time. If you use autofs to mount the cdrom instead of the GUI tools then the user that performs the mount is root. To work around this you can use the "uid=$UID" and "gid=$GID" options for the mount with the map that you're using. Note that the macros UID and GID aren't available for version 4 of autofs. Ian > To work around this you can use the "uid=$UID" and "gid=$GID" ...
This does change what 'mount' will show for CD mount options but
but, funnilly enough, does not have any influence on a gnome-eject
behaviour. Really minor thing. :-)
OTOH trying "user=$USER" and "group=$GROUP" instead seems to
make CD automount unmountable. I will try to look closer later.
|
Description of problem: With the following configuration in /etc/auto.master /net -hosts --timeout=60 /cd /etc/auto.cd --timeout=0 where /etc/auto.cd looks like that: cdrom -fstype=iso9660,ro,nosuid,nodev,user :/dev/cdrom and a corresponding line in /etc/fstab this used to mount CDs just fine on a reference to a directory /cd/cdrom. Not so with F8 installation running autofs-5.0.2-17 and kernel-2.6.23.8-63.fc8. Actually starting autofs prevents mounting on /cd/cdrom (assuming that this mount point exists) which otherwise works just like it should. Starting automount with options '-v -d' in /etc/sysconfig/autofs does not make me much wiser. I see automount[3029]: attempting to mount entry /cd/cdrom automount[3029]: lookup_mount: lookup(program): looking up cdrom automount[3029]: lookup(program): lookup for cdrom failed and that is about it. More extensive log excerpt follows: automount[3029]: Starting automounter version 5.0.2-17, master map auto.master automount[3029]: using kernel protocol version 5.00 automount[3029]: lookup_nss_read_master: reading master files auto.master automount[3029]: parse_init: parse(sun): init gathered global options: (null) automount[3029]: lookup_read_master: lookup(file): read entry /net automount[3029]: lookup_read_master: lookup(file): read entry /cd automount[3029]: master_do_mount: mounting /net automount[3029]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-net automount[3029]: lookup_nss_read_map: reading map hosts (null) automount[3029]: parse_init: parse(sun): init gathered global options: (null) automount[3029]: mounted indirect mount on /net with timeout 60, freq 15 seconds automount[3029]: master_do_mount: mounting /cd automount[3029]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-cd automount[3029]: lookup_nss_read_map: reading map file /etc/auto.cd automount[3029]: parse_init: parse(sun): init gathered global options: (null) automount[3029]: mounted indirect mount on /cd with timeouts disabled automount[3029]: st_expire: state 1 path /net automount[3029]: expire_proc: exp_proc = 3084016528 path /net automount[3029]: expire_cleanup: got thid 3084016528 path /net stat 0 automount[3029]: expire_cleanup: sigchld: exp 3084016528 finished, switching from 2 to 1 automount[3029]: st_ready: st_ready(): state = 2 path /net automount[3029]: st_expire: state 1 path /net automount[3029]: expire_proc: exp_proc = 3084016528 path /net automount[3029]: expire_cleanup: got thid 3084016528 path /net stat 0 automount[3029]: expire_cleanup: sigchld: exp 3084016528 finished, switching from 2 to 1 automount[3029]: st_ready: st_ready(): state = 2 path /net automount[3029]: handle_packet: type = 3 automount[3029]: handle_packet_missing_indirect: token 33, name cdrom, request pid 3045 automount[3029]: attempting to mount entry /cd/cdrom automount[3029]: lookup_mount: lookup(program): looking up cdrom automount[3029]: lookup(program): lookup for cdrom failed automount[3029]: send_fail: token = 33 automount[3029]: failed to mount /cd/cdrom automount[3029]: handle_packet: type = 3 automount[3029]: handle_packet_missing_indirect: token 34, name cdrom, request pid 3045 automount[3029]: attempting to mount entry /cd/cdrom automount[3029]: send_fail: token = 34 automount[3029]: failed to mount /cd/cdrom Automounts on /net work as expected. I cannot exclude possibility that hald and automount are getting into a foodfight over CDs even if the following policy file is present: <deviceinfo version="0.2"> <device> <match key="storage.hotpluggable" bool="false"> <match key="storage.drive_type" string="cdrom"> <merge key="storage.policy.should_mount" type="bool">false</merge> </match> </match> </device> </deviceinfo> which used to prevent that. Version-Release number of selected component (if applicable): autofs-5.0.2-17 How reproducible: always