Bug 961312 - Autofs ignore additional files from /etc/auto.master.d on same mountpoint
Autofs ignore additional files from /etc/auto.master.d on same mountpoint
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-09 07:46 EDT by Pavel Alexeev
Modified: 2013-07-07 20:51 EDT (History)
1 user (show)

See Also:
Fixed In Version: autofs-5.0.7-23.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-07 20:51:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/debug (45.08 KB, application/octet-stream)
2013-05-11 15:37 EDT, Pavel Alexeev
no flags Details
Patch - make dump maps check for duplicate indirect mounts (1.80 KB, patch)
2013-05-13 02:16 EDT, Ian Kent
no flags Details | Diff
Patch - document allowed map sources in auto.master(5) (1.63 KB, patch)
2013-05-13 02:18 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Pavel Alexeev 2013-05-09 07:46:38 EDT
Description of problem:
[root@hubbitus maps]# LANG=C ll -R /etc/auto.master.d
/etc/auto.master.d:
total 12
-rw-r--r-- 1 root root  386 May  9 15:29 m-n-p-y.autofs
drwxr-xr-x 2 root root 4096 May  9 14:48 maps
-rw-r--r-- 1 root root  132 May  9 15:29 nas-dmp.autofs

/etc/auto.master.d/maps:
total 8
-rw-r--r-- 1 root root 162 May  9 14:48 m-n-p-y.map
-rw-r--r-- 1 root root  45 May  9 14:43 nas-dmp.map

[root@hubbitus maps]# cat /etc/auto.master.d/m-n-p-y.autofs
e10fdeb5fc04f32fbbb50402d3c9f0dcdd688c85
/mnt/net /etc/auto.master.d/maps/m-n-p-y.map users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8 --timeout=300
[root@hubbitus maps]# cat /etc/auto.master.d/nas-dmp.autofs
/mnt/net /etc/auto.master.d/maps/nas-dmp.map users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8 --timeout=300

Note, both describe one mountpoint /mnt/net

Map-files map different directories there:
[root@hubbitus maps]# cat /etc/auto.master.d/maps/m-n-p-y.map
m -fstype=cifs ://192.168.100.199/maps
n -fstype=cifs ://192.168.100.199/distr
p -fstype=cifs ://192.168.100.199/Share
y -fstype=cifs ://192.168.100.199/updater
[root@hubbitus maps]# cat /etc/auto.master.d/maps/nas-dmp.map
dmp -fstype=cifs ://192.168.100.240/all/dmp

automount colect and correctly parse both:
[root@hubbitus maps]# automount -m | grep 'Mount point: /mnt/net' -A1000
Mount point: /mnt/net

source(s):

  instance type(s): file 
  map: /etc/auto.master.d/maps/m-n-p-y.map
  arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777 iocharset=utf8 

  p | -fstype=cifs ://192.168.100.199/Share
  y | -fstype=cifs ://192.168.100.199/updater
  m | -fstype=cifs ://192.168.100.199/maps
  n | -fstype=cifs ://192.168.100.199/distr

  instance type(s): file 
  map: /etc/auto.master.d/maps/nas-dmp.map
  arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777 iocharset=utf8 

  dmp | -fstype=cifs ://192.168.100.240/all/dmp

But when I start ayutofs I got error:
[root@hubbitus maps]# systemctl restart autofs.service

[root@hubbitus maps]# systemctl status autofs.service
autofs.service - Automounts filesystems on demand
   Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
   Active: active (running) since Чт. 2013-05-09 15:43:37 MSK; 13s ago
  Process: 1687 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 1691 (automount)
   CGroup: name=systemd:/system/autofs.service
           └─1691 /usr/sbin/automount --pid-file /run/autofs.pid

мая 09 15:43:37 hubbitus systemd[1]: Started Automounts filesystems on demand.
мая 09 15:43:37 hubbitus automount[1691]: key "dmp" not found in map source(s).
мая 09 15:43:37 hubbitus automount[1691]: key "s" not found in map source(s).

Additionally I can't understand why 'key "s" not found in map source' triggered. I had not found description where it sees it ti report what it should be defined such key at all.

Version-Release number of selected component (if applicable):
[pasha@hubbitus /]$ rpm -q autofs
autofs-5.0.7-13.fc18.x86_64

How reproducible:
Always
Comment 1 Ian Kent 2013-05-10 07:39:29 EDT
(In reply to comment #0)
> Description of problem:

I've read through this a few times over the last several days and
even though there's plenty of information I not quite sure what
the problem really is.

> [root@hubbitus maps]# LANG=C ll -R /etc/auto.master.d
> /etc/auto.master.d:
> total 12
> -rw-r--r-- 1 root root  386 May  9 15:29 m-n-p-y.autofs
> drwxr-xr-x 2 root root 4096 May  9 14:48 maps
> -rw-r--r-- 1 root root  132 May  9 15:29 nas-dmp.autofs
> 
> /etc/auto.master.d/maps:
> total 8
> -rw-r--r-- 1 root root 162 May  9 14:48 m-n-p-y.map
> -rw-r--r-- 1 root root  45 May  9 14:43 nas-dmp.map
> 
> [root@hubbitus maps]# cat /etc/auto.master.d/m-n-p-y.autofs
> e10fdeb5fc04f32fbbb50402d3c9f0dcdd688c85
> /mnt/net /etc/auto.master.d/maps/m-n-p-y.map
> users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8
> --timeout=300
> [root@hubbitus maps]# cat /etc/auto.master.d/nas-dmp.autofs
> /mnt/net /etc/auto.master.d/maps/nas-dmp.map
> users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8
> --timeout=300
> 
> Note, both describe one mountpoint /mnt/net

Right, the maps included here are meant to be master map fragments
and so should be subject to the same rules as when they are placed
directly in the master map.

Indirect maps aren't allowed to have multiple map sources.

> 
> Map-files map different directories there:
> [root@hubbitus maps]# cat /etc/auto.master.d/maps/m-n-p-y.map
> m -fstype=cifs ://192.168.100.199/maps
> n -fstype=cifs ://192.168.100.199/distr
> p -fstype=cifs ://192.168.100.199/Share
> y -fstype=cifs ://192.168.100.199/updater
> [root@hubbitus maps]# cat /etc/auto.master.d/maps/nas-dmp.map
> dmp -fstype=cifs ://192.168.100.240/all/dmp
> 
> automount colect and correctly parse both:
> [root@hubbitus maps]# automount -m | grep 'Mount point: /mnt/net' -A1000
> Mount point: /mnt/net
> 
> source(s):
> 
>   instance type(s): file 
>   map: /etc/auto.master.d/maps/m-n-p-y.map
>   arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777
> iocharset=utf8 
> 
>   p | -fstype=cifs ://192.168.100.199/Share
>   y | -fstype=cifs ://192.168.100.199/updater
>   m | -fstype=cifs ://192.168.100.199/maps
>   n | -fstype=cifs ://192.168.100.199/distr
> 
>   instance type(s): file 
>   map: /etc/auto.master.d/maps/nas-dmp.map
>   arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777
> iocharset=utf8 
> 
>   dmp | -fstype=cifs ://192.168.100.240/all/dmp

This function just reads and does some simple parsing of what it
gets. It doesn't do full validation.

This is misleading as it implies the second map instance of
/mnt/net is allowed when it isn't.

Not sure I have enough context to make that sort of determination
within this function but I agree it isn't correct.

> 
> But when I start ayutofs I got error:
> [root@hubbitus maps]# systemctl restart autofs.service
> 
> [root@hubbitus maps]# systemctl status autofs.service
> autofs.service - Automounts filesystems on demand
>    Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
>    Active: active (running) since Чт. 2013-05-09 15:43:37 MSK; 13s ago
>   Process: 1687 ExecStart=/usr/sbin/automount $OPTIONS --pid-file
> /run/autofs.pid (code=exited, status=0/SUCCESS)
>  Main PID: 1691 (automount)
>    CGroup: name=systemd:/system/autofs.service
>            └─1691 /usr/sbin/automount --pid-file /run/autofs.pid
> 
> мая 09 15:43:37 hubbitus systemd[1]: Started Automounts filesystems on
> demand.
> мая 09 15:43:37 hubbitus automount[1691]: key "dmp" not found in map
> source(s).
> мая 09 15:43:37 hubbitus automount[1691]: key "s" not found in map source(s).
> 
> Additionally I can't understand why 'key "s" not found in map source'
> triggered. I had not found description where it sees it ti report what it
> should be defined such key at all.

Those messages are telling you that automount received a lookup
for a directory, what automount is calling the key, and that key
was not present in the map which is accurate as far as I can see.

Just because you have not defined a key "s" in the map  doesn't
mean that some application can't attempt to access "s" within
the /mnt/net directory.

Ian
Comment 2 Pavel Alexeev 2013-05-10 13:49:04 EDT
(In reply to comment #1)
> (In reply to comment #0)

> > Note, both describe one mountpoint /mnt/net
> 
> Right, the maps included here are meant to be master map fragments
> and so should be subject to the same rules as when they are placed
> directly in the master map.
> 
> Indirect maps aren't allowed to have multiple map sources.
> 
...
> > 
> >   dmp | -fstype=cifs ://192.168.100.240/all/dmp
> 
> This function just reads and does some simple parsing of what it
> gets. It doesn't do full validation.
> 
> This is misleading as it implies the second map instance of
> /mnt/net is allowed when it isn't.
> 
> Not sure I have enough context to make that sort of determination
> within this function but I agree it isn't correct.

Autofs service actually is just call automount (/lib/systemd/system/autofs.service):
ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid

So if automount in dump show parsed keys, but do not mount them it is bug in any case in one of places.

> This is misleading as it implies the second map instance of
> /mnt/net is allowed when it isn't.
Why not? I have not found such in man. Could you please point me on such statement in documentation?

> > Additionally I can't understand why 'key "s" not found in map source'
> > triggered. I had not found description where it sees it ti report what it
> > should be defined such key at all.
> 
> Those messages are telling you that automount received a lookup
> for a directory, what automount is calling the key, and that key
> was not present in the map which is accurate as far as I can see.
> 
> Just because you have not defined a key "s" in the map  doesn't
> mean that some application can't attempt to access "s" within
> the /mnt/net directory.

Strange.

[root@hubbitus ~]# ls /mnt/net/
dmp  m  n  ovh  p  s  smb  y
[root@hubbitus ~]# ls /mnt/net/s
[root@hubbitus ~]# rmdir /mnt/net/s
[root@hubbitus ~]# ls /mnt/net/s
ls: cannot access /mnt/net/s: No such file or directory
[root@hubbitus ~]# ls /mnt/net/
dmp  m  n  ovh  p  smb  y
[root@hubbitus ~]#
[root@hubbitus ~]# systemctl restart autofs.service
[root@hubbitus ~]# systemctl status autofs.service
autofs.service - Automounts filesystems on demand
   Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
   Active: active (running) since Пт. 2013-05-10 21:45:46 MSK; 19s ago
  Process: 13922 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 13924 (automount)
   CGroup: name=systemd:/system/autofs.service
           └─13924 /usr/sbin/automount --pid-file /run/autofs.pid

мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on demand...
мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on demand.
мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map source(s).
Comment 3 Ian Kent 2013-05-10 21:15:51 EDT
(In reply to comment #2)
> > > Note, both describe one mountpoint /mnt/net
> > 
> > Right, the maps included here are meant to be master map fragments
> > and so should be subject to the same rules as when they are placed
> > directly in the master map.
> > 
> > Indirect maps aren't allowed to have multiple map sources.
> > 
> ...
> > > 
> > >   dmp | -fstype=cifs ://192.168.100.240/all/dmp
> > 
> > This function just reads and does some simple parsing of what it
> > gets. It doesn't do full validation.
> > 
> > This is misleading as it implies the second map instance of
> > /mnt/net is allowed when it isn't.
> > 
> > Not sure I have enough context to make that sort of determination
> > within this function but I agree it isn't correct.
> 
> Autofs service actually is just call automount
> (/lib/systemd/system/autofs.service):
> ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
> 
> So if automount in dump show parsed keys, but do not mount them it is bug in
> any case in one of places.

systemd doesn't have anything to do with this.
automount does mount /mnt/net but ignores duplicate entries in the
master map for indirect mounts.

I've already said that the map dumping function isn't doing what it
should be doing but I also said I'm not sure I have enough context
within the dump maps function to identify duplicates and issue an
informative message.

I'll have a look and see what I can do.

> 
> > This is misleading as it implies the second map instance of
> > /mnt/net is allowed when it isn't.
> Why not? I have not found such in man. Could you please point me on such
> statement in documentation?

I don't think the documentation says that explicitly. But the
documentation doesn't say you can have multiple entries for
direct maps either although you can.

Very early in the version 5 development multiple indirect map
entries were allowed.

There was some discussion about it but I can't remember now what
the actual problem was. Since one of the goals for version 5 was to
behave the same as Solaris autofs as much as we could and that didn't
allow multiple indirect map entries the functionality was removed.
Now, since so much has changed, to add it back would be quite
difficult and then there's the change in behaviour that was a
problem in the beginning to consider.

> 
> > > Additionally I can't understand why 'key "s" not found in map source'
> > > triggered. I had not found description where it sees it ti report what it
> > > should be defined such key at all.
> > 
> > Those messages are telling you that automount received a lookup
> > for a directory, what automount is calling the key, and that key
> > was not present in the map which is accurate as far as I can see.
> > 
> > Just because you have not defined a key "s" in the map  doesn't
> > mean that some application can't attempt to access "s" within
> > the /mnt/net directory.
> 
> Strange.
> 
> [root@hubbitus ~]# ls /mnt/net/
> dmp  m  n  ovh  p  s  smb  y
> [root@hubbitus ~]# ls /mnt/net/s
> [root@hubbitus ~]# rmdir /mnt/net/s
> [root@hubbitus ~]# ls /mnt/net/s
> ls: cannot access /mnt/net/s: No such file or directory
> [root@hubbitus ~]# ls /mnt/net/
> dmp  m  n  ovh  p  smb  y
> [root@hubbitus ~]#
> [root@hubbitus ~]# systemctl restart autofs.service
> [root@hubbitus ~]# systemctl status autofs.service
> autofs.service - Automounts filesystems on demand
>    Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
>    Active: active (running) since Пт. 2013-05-10 21:45:46 MSK; 19s ago
>   Process: 13922 ExecStart=/usr/sbin/automount $OPTIONS --pid-file
> /run/autofs.pid (code=exited, status=0/SUCCESS)
>  Main PID: 13924 (automount)
>    CGroup: name=systemd:/system/autofs.service
>            └─13924 /usr/sbin/automount --pid-file /run/autofs.pid
> 
> мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on
> demand...
> мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on
> demand.
> мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map
> source(s).

I don't see that.

I'll need to duplicate more closely the map entries your using
and see if I can reproduce it.

Ian
Comment 4 Ian Kent 2013-05-10 22:31:19 EDT
(In reply to comment #3)
> > 
> > мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on
> > demand...
> > мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on
> > demand.
> > мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map
> > source(s).
> 
> I don't see that.
> 
> I'll need to duplicate more closely the map entries your using
> and see if I can reproduce it.

I can't reproduce this.

Can you post a full debug log please.

You can get a debug log by ensuring that facility daemon is being
recorded in syslog. I do that by adding a line like:

daemon.*                /var/log/debug

to rsyslog.conf, then create /var/log/debug and restart rsyslog.

Then set LOGGING="debug" in /etc/sysconfig/autofs.
Comment 5 Pavel Alexeev 2013-05-11 15:17:07 EDT
(In reply to comment #3)
> (In reply to comment #2)
> 
> I've already said that the map dumping function isn't doing what it
> should be doing but I also said I'm not sure I have enough context
> within the dump maps function to identify duplicates and issue an
> informative message.
> 
> I'll have a look and see what I can do.

> > > This is misleading as it implies the second map instance of
> > > /mnt/net is allowed when it isn't.
> > Why not? I have not found such in man. Could you please point me on such
> > statement in documentation?
> 
> I don't think the documentation says that explicitly. But the
> documentation doesn't say you can have multiple entries for
> direct maps either although you can.
> 
> Very early in the version 5 development multiple indirect map
> entries were allowed.
> 
> There was some discussion about it but I can't remember now what
> the actual problem was. Since one of the goals for version 5 was to
> behave the same as Solaris autofs as much as we could and that didn't
> allow multiple indirect map entries the functionality was removed.
> Now, since so much has changed, to add it back would be quite
> difficult and then there's the change in behaviour that was a
> problem in the beginning to consider.

In such case it will be more than desire have such checks and catch in dump function to avoid similar confusions.

In any case, thank you very much for the ansvers and help.
Comment 6 Pavel Alexeev 2013-05-11 15:37:13 EDT
Created attachment 746634 [details]
/var/log/debug

(In reply to comment #4)
> (In reply to comment #3)
> I can't reproduce this.
> 
> Can you post a full debug log please.
> 
> You can get a debug log by ensuring that facility daemon is being
> recorded in syslog. I do that by adding a line like:
> 
> daemon.*                /var/log/debug
> 
> to rsyslog.conf, then create /var/log/debug and restart rsyslog.
> 
> Then set LOGGING="debug" in /etc/sysconfig/autofs.
It was just a note...
If you so kind to look on it too, may be it have worth to splitout in separate bug?

/var/log/debug file attached.
Comment 7 Ian Kent 2013-05-12 21:51:50 EDT
(In reply to comment #5)
> 
> > > > This is misleading as it implies the second map instance of
> > > > /mnt/net is allowed when it isn't.
> > > Why not? I have not found such in man. Could you please point me on such
> > > statement in documentation?
> > 
> > I don't think the documentation says that explicitly. But the
> > documentation doesn't say you can have multiple entries for
> > direct maps either although you can.
> > 
> > Very early in the version 5 development multiple indirect map
> > entries were allowed.
> > 
> > There was some discussion about it but I can't remember now what
> > the actual problem was. Since one of the goals for version 5 was to
> > behave the same as Solaris autofs as much as we could and that didn't
> > allow multiple indirect map entries the functionality was removed.
> > Now, since so much has changed, to add it back would be quite
> > difficult and then there's the change in behaviour that was a
> > problem in the beginning to consider.
> 
> In such case it will be more than desire have such checks and catch in dump
> function to avoid similar confusions.

Yep, I'm working on that now and I'll add something to the man page
of auto.master(5).
Comment 8 Ian Kent 2013-05-13 02:16:58 EDT
Created attachment 747085 [details]
Patch - make dump maps check for duplicate indirect mounts
Comment 9 Ian Kent 2013-05-13 02:18:16 EDT
Created attachment 747087 [details]
Patch - document allowed map sources in auto.master(5)
Comment 10 Ian Kent 2013-05-13 03:05:23 EDT
(In reply to comment #6)
> Created attachment 746634 [details]
> /var/log/debug

snip ...

> > 
> > Then set LOGGING="debug" in /etc/sysconfig/autofs.
> It was just a note...
> If you so kind to look on it too, may be it have worth to splitout in
> separate bug?
> 
> /var/log/debug file attached.

I've had a look at the debug log.

First thing is autofs wasn't shutdown cleanly when you shut it down.

That normally just means that one or more mounts were in use at the
time and autofs should re-connect to those active mounts when it
starts again.

That shouldn't be a problem but can result in unexpected behaviour
at times. For example, when an autofs mount is busy it doesn't get
umounted at shutdown so any previously created mount point directories,
that for whatever reason weren't removed at umount or shutdown, will
remain and can lead to lookups like what you see here.

Another possibility is that some process is attempting to access
/mnt/net/s, perhaps because diectory "s" exists due to the above
and it is scanning the directory or because the process is trying
to access the specific path /mnt/net/s. Whatever the reason is the
kernel is duty bound to call back to the daemon with the directory
as the key.

Note that for this to happen with indirect mounts (like this) the
directory doesn't need to already exist to trigger a callback. In
this case there's no way for the kernel to know if the key is
valid or not and it must call back to the daemon.

If you do have a bad directory in /mnt/net then shut down autofs,
ensure any remaining mount points are not in use then manually
umount all the remaining autofs mananged mounts in dependency order,
including the autofs mount itself, /mnt/net, in this case. The goal
is to get the base autofs mount umounted before starting autofs
again.

That will clean up any old mount point directories because the
autofs file system is memory based.

The other way to reset the autofs mount is, of course, to
schedule a reboot of the system.

It's true that this shouldn't happen but it does from time to time.
I do work to improve it when I get reports that lead to a reason
for it happening but even then it can be hard to work out why it
happened. It's virtually impossible to guess what may have happened
previously to cause it when there isn't a reported way to reproduce
it.

Ian
Comment 11 Fedora Update System 2013-05-13 03:22:23 EDT
autofs-5.0.7-16.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-16.fc19
Comment 12 Fedora Update System 2013-05-13 03:23:20 EDT
autofs-5.0.7-16.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/autofs-5.0.7-16.fc18
Comment 13 Pavel Alexeev 2013-05-13 15:18:09 EDT
Ian thank you vry much for you effort and deep explanation. Reboot helps me.
Comment 14 Fedora Update System 2013-05-13 21:24:50 EDT
Package autofs-5.0.7-16.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.7-16.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8061/autofs-5.0.7-16.fc18
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2013-05-24 01:50:10 EDT
autofs-5.0.7-17.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-17.fc19
Comment 16 Fedora Update System 2013-05-27 06:13:35 EDT
autofs-5.0.7-19.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-19.fc19
Comment 17 Fedora Update System 2013-06-11 04:36:45 EDT
autofs-5.0.7-20.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-20.fc19
Comment 18 Fedora Update System 2013-06-13 03:11:47 EDT
autofs-5.0.7-21.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-21.fc19
Comment 19 Fedora Update System 2013-06-19 00:14:12 EDT
autofs-5.0.7-22.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-22.fc19
Comment 20 Fedora Update System 2013-06-28 01:58:53 EDT
autofs-5.0.7-23.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-23.fc19
Comment 21 Fedora Update System 2013-07-07 20:51:59 EDT
autofs-5.0.7-23.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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