Bug 475180 - /net mounts fail from time to time
/net mounts fail from time to time
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
10
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-08 06:39 EST by Tomasz Kepczynski
Modified: 2009-12-18 02:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:12:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
autofs messages in /var/log/messages (14.13 KB, text/plain)
2008-12-08 06:39 EST, Tomasz Kepczynski
no flags Details

  None (edit)
Description Tomasz Kepczynski 2008-12-08 06:39:54 EST
Created attachment 326114 [details]
autofs messages in /var/log/messages

Description of problem:
I use /net quite extensively to access shared network resources. I began having problems with access to one of the servers since I upgraded from F8 to F10.
If I do:
gklab-59-001:~> ls -l /net/gksfiler04/vol/*

I get:
/net/gksfiler04/vol/vol0:
razem 20
-rw-r--r-- 1 kwasilew ccigk    6 lis 13 15:17 myfile
-rw-r--r-- 1    65534 65534  112 lis  4 01:34 test_from_root@lab.txt
-rw-r--r-- 1 root     root    91 lis  4 14:42 test_from_root@production.txt
-rw-r----- 1 amaczuga ccigk  112 lis  4 01:36 test_from_underling@lab.txt
-rw-r----- 1 amaczuga ccigk   91 lis  4 14:43 test_from_underling@production.txt
drwxrwxrwx 2 mswirydc ccigk 4096 lis  4 13:55 test_from_Windows
-rwxrwxrwx 1 mswirydc ccigk    4 lis  4 13:55 test_from_windows.txt

/net/gksfiler04/vol/vol1:
razem 20
-rw-r--r-- 1 kwasilew ccigk    6 lis 13 15:17 myfile
-rw-r--r-- 1    65534 65534  112 lis  4 01:34 test_from_root@lab.txt
-rw-r--r-- 1 root     root    91 lis  4 14:42 test_from_root@production.txt
-rw-r----- 1 amaczuga ccigk  112 lis  4 01:36 test_from_underling@lab.txt
-rw-r----- 1 amaczuga ccigk   91 lis  4 14:43 test_from_underling@production.txt
drwxrwxrwx 2 mswirydc ccigk 4096 lis  4 13:55 test_from_Windows
-rwxrwxrwx 1 mswirydc ccigk    4 lis  4 13:55 test_from_windows.txt

/net/gksfiler04/vol/vol2:
razem 20
-rw-r--r-- 1 kwasilew ccigk    6 lis 13 15:17 myfile
-rw-r--r-- 1    65534 65534  112 lis  4 01:34 test_from_root@lab.txt
-rw-r--r-- 1 root     root    91 lis  4 14:42 test_from_root@production.txt
-rw-r----- 1 amaczuga ccigk  112 lis  4 01:36 test_from_underling@lab.txt
-rw-r----- 1 amaczuga ccigk   91 lis  4 14:43 test_from_underling@production.txt
drwxrwxrwx 2 mswirydc ccigk 4096 lis  4 13:55 test_from_Windows
-rwxrwxrwx 1 mswirydc ccigk    4 lis  4 13:55 test_from_windows.txt

while I expected:
ls: /net/gksfiler04/vol/vol0: No such file or directory
/net/gksfiler04/vol/vol1:
total 4
drwxrwx---  7 gkbld_nand gk_nand 4096 2008-09-10 15:13 NPG-nand

/net/gksfiler04/vol/vol2:
total 12
drwxrwxrwx  4 root root 4096 2008-11-14 15:00 BCG-softcreek-public
drwxr-xr-x  8 root root 4096 2008-07-11 22:42 igk_ec_disk004
drwxrwxr-x  6 root root 4096 2008-05-30 16:39 labsoftware

The export list is:
showmount -e gksfiler04
Export list for gksfiler04:
/vol/vol1/NPG-nand             igk_prod_all,igk_admin,172.28.56.0/21,172.28.184.0/24,172.28.185.0/24,172.28.186.0/24,172.28.188.0/24,172.28.190.0/23,172.28.62.0/24,172.28.81.0/24
/vol/vol0                      igk_admin
/vol/vol1                      igk_admin
/vol/vol2                      igk_prod_all,igk_admin
/vol/vol2/labsoftware          igk_prod_all,igk_admin,172.28.56.0/21,172.28.184.0/24,172.28.185.0/24,172.28.186.0/24,172.28.188.0/24,172.28.190.0/23,172.28.62.0/24,172.28.81.0/24
/vol/vol2/BCG-softcreek-public (everyone)
/vol/vol2/igk_ec_disk004       igk_prod_all,igk_admin,172.28.56.0/21,172.28.184.0/24,172.28.185.0/24,172.28.186.0/24,172.28.188.0/24,172.28.190.0/23,172.28.62.0/24,172.28.81.0/24

The problem appears regardless usage /etc/auto.net or -hosts in /etc/auto.master.

F8 with latest updates applied works OK.
I've spotted some failures from autofs (with debug logging on) which I attach.

Version-Release number of selected component (if applicable):
autofs-5.0.3-36.x86_64

How reproducible:
Often. The contents of directories changes from time to time, I often get "stale nfs handle" or permission denied messages (especially when I try to cd into one of the imported directories).

Actual results:
/net is useless for me.

Expected results:
/net works

The following information may be relevant to this bug:
- selinux is enforcing (I haven't try to disable)
- /tmp is tmpfs, no disk backed storage
Comment 1 Ian Kent 2008-12-08 07:09:32 EST
Do the mount point directories, such as gksfiler04:/vol/vol1/NPG-nand,
actually exist. IOW are the permission denied messages in the log
incorrect?

Ian
Comment 2 Tomasz Kepczynski 2008-12-09 02:57:29 EST
/vol/vol0 - the access is disabled on server level by netgroup
/vol/vol1 - as above
/vol/vol2 - the access is enabled
/vol/vol1/NPG-nand - the access is enabled on a server level, but I do not have permissions to access it
/vol/vol2/labsoftware - I have access
/vol/vol2/BCG-softcreek-public - I have access
/vol/vol2/igk_ec_disk004 - I have access

The directory listed above (in my original filing) under /vol/vol0, /vol/vol1 and /vol/vol2 is actually /vol/vol2/BCG-softcreek-public
Comment 3 Ian Kent 2008-12-09 03:19:45 EST
(In reply to comment #2)
> /vol/vol0 - the access is disabled on server level by netgroup
> /vol/vol1 - as above
> /vol/vol2 - the access is enabled
> /vol/vol1/NPG-nand - the access is enabled on a server level, but I do not have
> permissions to access it
> /vol/vol2/labsoftware - I have access
> /vol/vol2/BCG-softcreek-public - I have access
> /vol/vol2/igk_ec_disk004 - I have access
> 
> The directory listed above (in my original filing) under /vol/vol0, /vol/vol1
> and /vol/vol2 is actually /vol/vol2/BCG-softcreek-public

Right, that's important information.

It may be little more than incorrect paths used for the preparation
of a mount tree under the temporary directory. I'm still working
to understanding what's is going on here. The access control on
the exports makes it a little hard to digest.

It's worth pointing out that there are some cases where we cannot
prevent processes from walking into a mount tree while it is under
construction, from within the kernel module, and this is why the
change has been made.

Sorry for the inconvenience and the delay.
Ian
Comment 4 Ian Kent 2008-12-09 23:08:15 EST
Can you provide a full debug log, not just the partial log
above please.
Comment 5 Ian Kent 2008-12-09 23:20:00 EST
(In reply to comment #2)
> /vol/vol0 - the access is disabled on server level by netgroup
> /vol/vol1 - as above
> /vol/vol2 - the access is enabled
> /vol/vol1/NPG-nand - the access is enabled on a server level, but I do not have
> permissions to access it
> /vol/vol2/labsoftware - I have access
> /vol/vol2/BCG-softcreek-public - I have access
> /vol/vol2/igk_ec_disk004 - I have access

Another permissions question.

For example do you have permission to access the mount point
directories (to allow stat(2)) themselves /vol/vol2/igk_ec_disk004
and /vol/vol2/labsoftware.
Comment 6 Ian Kent 2008-12-09 23:23:05 EST
(In reply to comment #0)
> 
> F8 with latest updates applied works OK.

Does the F8 package built on your F-10 install also work?

Ian
Comment 7 Tomasz Kepczynski 2008-12-10 04:26:10 EST
The log I've sent you was not filtered, just cut from top and bottom (and you probably don't care about full /var/log/messages which is several megabytes). Could you be a bit more specific what information you want included?
I do have access to /vol/vol2/igk_ec_disk004 and /vol/vol2/labsoftware, I can cd there and list directory contents.
Comment 8 Ian Kent 2008-12-10 08:14:34 EST
(In reply to comment #7)
> The log I've sent you was not filtered, just cut from top and bottom (and you
> probably don't care about full /var/log/messages which is several megabytes).
> Could you be a bit more specific what information you want included?

Yeah, I know but you never know what you might miss.

For example the log snippet provided does not show where the
incorrect mount that you end up seeing first starts to happen.

While I still may not get more info. from the full log I must
look. A "grep automount /var/log/messages > somefile" would be
enough. Compress it and if it's too big send it directly to me
at ikent@redhat.com.

> I do have access to /vol/vol2/igk_ec_disk004 and /vol/vol2/labsoftware, I can
> cd there and list directory contents.

Sure but that's not what I asked.

Do you have permission (aka rx) to the "underlying" mount
point directory. In the above log the stat(2) on this directory
is failing but it could be some other reason, possibly that the
badness has already happened by this time.

Ian
Comment 9 Tomasz Kepczynski 2008-12-10 10:00:02 EST
> Yeah, I know but you never know what you might miss.
> 
> For example the log snippet provided does not show where the
> incorrect mount that you end up seeing first starts to happen.
> 
> While I still may not get more info. from the full log I must
> look. A "grep automount /var/log/messages > somefile" would be
> enough. Compress it and if it's too big send it directly to me
> at ikent@redhat.com.

I will try to prepare full log and as you suggested - I'll send it directly to you.

> Do you have permission (aka rx) to the "underlying" mount
> point directory. In the above log the stat(2) on this directory
> is failing but it could be some other reason, possibly that the
> badness has already happened by this time.

Ok, I am not sure what you are asking for:
1. the permissions of the "mount point"
2. the permissions of the directory exported from server?
Would it be enough if I do 'ls -laR' or find -ls -depth <n> on /net/gksfiler04?

Tomek
Comment 10 Tomasz Kepczynski 2008-12-10 10:39:51 EST
F8 autofs does not work, even seems to be less stable.
Comment 11 Ian Kent 2008-12-10 11:45:43 EST
(In reply to comment #9)
> > Yeah, I know but you never know what you might miss.
> > 
> > For example the log snippet provided does not show where the
> > incorrect mount that you end up seeing first starts to happen.
> > 
> > While I still may not get more info. from the full log I must
> > look. A "grep automount /var/log/messages > somefile" would be
> > enough. Compress it and if it's too big send it directly to me
> > at ikent@redhat.com.
> 
> I will try to prepare full log and as you suggested - I'll send it directly to
> you.
> 
> > Do you have permission (aka rx) to the "underlying" mount
> > point directory. In the above log the stat(2) on this directory
> > is failing but it could be some other reason, possibly that the
> > badness has already happened by this time.
> 
> Ok, I am not sure what you are asking for:
> 1. the permissions of the "mount point"
> 2. the permissions of the directory exported from server?

In this case the mount point is the directory within the exported
file system on the server, eg. the directory labsoftware within
/vol/vol2 on the server when nothing is mounted on it. That could
be seen by manually mounting gksfiler04:/vol/vol2 somewhere and
doing an ls -l on the mount.

> Would it be enough if I do 'ls -laR' or find -ls -depth <n> on /net/gksfiler04?

No because the directory would be covered by the mount, if things
were working ok, but since they aren't then you likely won't see
the needed directory anyway.

The question I'm trying to answer is "why am I seeing a permission
denied return when I expect a directory exists return". In the
past there have been problems where a stat(2) on an NFS mounted
directory would return an access error before an exists error but
I though I worked around that.

problems related to
Comment 12 Ian Kent 2008-12-10 12:26:41 EST
What is the line you use to mount tmpfs on /tmp?
Comment 13 Tomasz Kepczynski 2008-12-10 14:32:50 EST
(In reply to comment #12)
> What is the line you use to mount tmpfs on /tmp?

I don't have access to PC in question but I am 99% sure the line is:
tmpfs                   /tmp                    tmpfs   size=1G         0 0

Size may differ (but this is very unlikely), I dont' put any other options.
Comment 14 Tomasz Kepczynski 2008-12-10 14:50:29 EST
(In reply to comment #11)
> > Ok, I am not sure what you are asking for:
> > 1. the permissions of the "mount point"
> > 2. the permissions of the directory exported from server?
> 
> In this case the mount point is the directory within the exported
> file system on the server, eg. the directory labsoftware within
> /vol/vol2 on the server when nothing is mounted on it. That could
> be seen by manually mounting gksfiler04:/vol/vol2 somewhere and
> doing an ls -l on the mount.
> 
> > Would it be enough if I do 'ls -laR' or find -ls -depth <n> on /net/gksfiler04?
> 
> No because the directory would be covered by the mount, if things
> were working ok, but since they aren't then you likely won't see
> the needed directory anyway.
> 
> The question I'm trying to answer is "why am I seeing a permission
> denied return when I expect a directory exists return". In the
> past there have been problems where a stat(2) on an NFS mounted
> directory would return an access error before an exists error but
> I though I worked around that.
> 
> problems related to
OK, I still don't fully understand what you would like to know, so I ask a few questions:
- do you need showmount -e on gksfiler04?
- I can manually mount any of directories in question (with exception of the ones I am not allowed to), would the ls -l this way help?
- I can log into another machine (probably SLES9), go to /net/gksfiler04 there and do ls -l, would that help?
- I can also boot F8

Whatever you choose, I'll do it tomorrow.

On a side note, I have problems with another server on /net with -hosts map which works with /etc/auto.net (I was going to reporte a bug on that later on) and as far as I remember I saw some permission problems there as well. I either can send you logs in this bug or I can file a new one to give you all the information together to ease troubleshooting.
Comment 15 Ian Kent 2008-12-10 20:26:32 EST
(In reply to comment #14)
> > problems related to
> OK, I still don't fully understand what you would like to know, so I ask a few
> questions:
> - do you need showmount -e on gksfiler04?

No, you already posted that.

> - I can manually mount any of directories in question (with exception of the
> ones I am not allowed to), would the ls -l this way help?

That's what I asked you to do.

> - I can log into another machine (probably SLES9), go to /net/gksfiler04 there
> and do ls -l, would that help?

No, the directories in question will probably have a mount on
top of them.

> - I can also boot F8

Should be the same with the current package.

> 
> Whatever you choose, I'll do it tomorrow.

Assuming directory /mnt/tmp is not being used for anything else.

mkdir /mnt/tmp
mount -t nfs gksfiler04:/vol/vol2 /mnt/tmp
ls -l /mnt/tmp
<post output from the above command>
umount /mnt/tmp

> 
> On a side note, I have problems with another server on /net with -hosts map
> which works with /etc/auto.net (I was going to reporte a bug on that later on)
> and as far as I remember I saw some permission problems there as well. I either
> can send you logs in this bug or I can file a new one to give you all the
> information together to ease troubleshooting.

One thing at a time.
Perhaps it is good idea to log another bug now, your choice.

Ian
Comment 16 Tomasz Kepczynski 2008-12-11 02:47:38 EST
OK, I am puzzled even more. Please follow closely.

gklab-59-001:~# mount gksfiler04:/vol/vol0 /mnt
mount.nfs: access denied by server while mounting gksfiler04:/vol/vol0
gklab-59-001:~# mount gksfiler04:/vol/vol0 /mnt
gklab-59-001:~# ls -la /mnt/
ls: cannot open directory /mnt/: Permission denied
gklab-59-001:~# ls -la /mnt/
ls: cannot open directory /mnt/: Permission denied
gklab-59-001:~# umou
umount      umount.cifs umount.hal  umount.nfs  umount.nfs4
gklab-59-001:~# umount /mnt/
gklab-59-001:~# mount gksfiler04:/vol/vol0 /mnt
gklab-59-001:~# ls -la /mnt/
ls: cannot open directory /mnt/: Permission denied
gklab-59-001:~# umount /mnt/
gklab-59-001:~# mount gksfiler04:/vol/vol0 /mnt
gklab-59-001:~# ls -la /mnt/
ls: cannot open directory /mnt/: Permission denied
gklab-59-001:~# umount /mnt/

The server shouldn't allow me to mount that directory at all, so maybe this is the problem on the other side...

gklab-59-001:~# mount gksfiler04:/vol/vol1 /mnt
gklab-59-001:~# ls -la /mnt/
ls: /mnt/.snapshot: Permission denied
total 36
drwxrwxrwx  4 root     root  4096 2008-11-14 15:00 .
drwxr-xr-x 26 root     root  4096 2008-12-10 11:38 ..
-rw-r--r--  1 kwasilew ccigk    6 2008-11-13 15:17 myfile
drwxrwxrwx  6 root     root  4096 2008-12-11 00:01 .snapshot
-rw-r--r--  1    65534 65534  112 2008-11-04 01:34 test_from_root@lab.txt
-rw-r--r--  1 root     root    91 2008-11-04 14:42 test_from_root@production.txt
-rw-r-----  1 amaczuga ccigk  112 2008-11-04 01:36 test_from_underling@lab.txt
-rw-r-----  1 amaczuga ccigk   91 2008-11-04 14:43 test_from_underling@production.txt
drwxrwxrwx  2 mswirydc ccigk 4096 2008-11-04 13:55 test_from_Windows
-rwxrwxrwx  1 mswirydc ccigk    4 2008-11-04 13:55 test_from_windows.txt
gklab-59-001:~# umount /mnt/

That's not the correct content of this directory....

gklab-59-001:~# mount gksfiler04:/vol/vol2 /mnt
gklab-59-001:~# ls -la /mnt/
ls: cannot open directory /mnt/: Stale NFS file handle
gklab-59-001:~# ls -la /mnt/                          
ls: cannot access /mnt/: Stale NFS file handle        
gklab-59-001:~# umount /mnt/
gklab-59-001:~# mount gksfiler04:/vol/vol2 /mnt
mount.nfs: mount point /mnt is not a directory
gklab-59-001:~# umount /mnt/
umount: /mnt/: not mounted
gklab-59-001:~# mount gksfiler04:/vol/vol2 /mnt
mount.nfs: mount point /mnt is not a directory
gklab-59-001:~# mount gksfiler04:/vol/vol2 /mnt
gklab-59-001:~# ls -la /mnt/
ls: /mnt/.snapshot: Permission denied
total 36
drwxrwxrwx  4 root     root  4096 2008-11-14 15:00 .
drwxr-xr-x 26 root     root  4096 2008-12-10 11:38 ..
-rw-r--r--  1 kwasilew ccigk    6 2008-11-13 15:17 myfile
drwxrwxrwx  6 root     root  4096 2008-12-11 00:01 .snapshot
-rw-r--r--  1    65534 65534  112 2008-11-04 01:34 test_from_root@lab.txt
-rw-r--r--  1 root     root    91 2008-11-04 14:42 test_from_root@production.txt
-rw-r-----  1 amaczuga ccigk  112 2008-11-04 01:36 test_from_underling@lab.txt
-rw-r-----  1 amaczuga ccigk   91 2008-11-04 14:43 test_from_underling@production.txt
drwxrwxrwx  2 mswirydc ccigk 4096 2008-11-04 13:55 test_from_Windows
-rwxrwxrwx  1 mswirydc ccigk    4 2008-11-04 13:55 test_from_windows.txt
gklab-59-001:~# mount gksfiler04:/vol/vol2 /mnt
mount.nfs: /mnt is busy or already mounted
gklab-59-001:~# umount /mnt/

Again - once I mount it the content is wrong, I'll pass that to our IT staff and come back with the update.

One important thing - I've updated kernel yesterday to kernel-2.6.27.7-134.fc10.x86_64.
Comment 17 Tomasz Kepczynski 2008-12-11 02:51:02 EST
I've also seen this (once) in dmesg:
NFS: server gksfiler04 error: fileid changed
fsid 0:19: expected fileid 0xb654da, got 0x1fb6701
Comment 18 Tomasz Kepczynski 2008-12-11 05:04:09 EST
For a comment #16: the fact that I was able to mount directories which I am not allowed to seems to be a kernel issue - I've tried to mount them on F8 and received correct error indication:

mount gksfiler04:/vol/vol0 /mnt
mount.nfs: gksfiler04:/vol/vol0 failed, reason given by server: Permission denied
gklab-59-001:~# mount gksfiler04:/vol/vol2
mount.nfs: gksfiler04:/vol/vol2 failed, reason given by server: Permission denied
gklab-59-001:~# mount gksfiler04:/vol/vol1
mount.nfs: gksfiler04:/vol/vol1 failed, reason given by server: Permission denied

I've double checked netgroups and I do not have permission to mount /vol/vol2.
Comment 19 Ian Kent 2008-12-11 08:15:23 EST
(In reply to comment #17)
> I've also seen this (once) in dmesg:
> NFS: server gksfiler04 error: fileid changed
> fsid 0:19: expected fileid 0xb654da, got 0x1fb6701

Right, you might find bug 472778 interesting, especially comment #4
relating to the NetApp snapshot implementation.
Comment 20 Ian Kent 2008-12-11 08:18:52 EST
(In reply to comment #18)
> For a comment #16: the fact that I was able to mount directories which I am not
> allowed to seems to be a kernel issue - I've tried to mount them on F8 and
> received correct error indication:

So the plot thickens.
Certainly got me scratching my head.

But, on second thoughts, the the NFS mount option handling
has been moved into the kernel now. I wonder if that has
any implications for netgroup type ACL handling?
Comment 21 Tomasz Kepczynski 2008-12-11 10:40:01 EST
I've tried to reproduce this issue on my own nfs server by disallowing access for <top> directory and allowing to <top>/<bottom> but was unsuccessful. But I did it by using netmasks so I will try to employ netgroups tomorrow and see what happens then.
Comment 22 Jeff Layton 2008-12-11 10:57:37 EST
I wouldn't think that the mount option handling would have any effect on netgroup mount ACL handling. The nfs client essentially doesn't care what the server's mount permissions look like. We simply attempt the mount and it's up to the server to allow or deny it.

The first comment is interesting however. The fact that you're seeing the wrong contents in the directory sort of indicates that the filehandle being returned by the server for the mount is wrong.

You said this:

-----------------[snip]------------------

gklab-59-001:~# mount gksfiler04:/vol/vol1 /mnt
gklab-59-001:~# ls -la /mnt/
ls: /mnt/.snapshot: Permission denied
total 36
drwxrwxrwx  4 root     root  4096 2008-11-14 15:00 .
drwxr-xr-x 26 root     root  4096 2008-12-10 11:38 ..
-rw-r--r--  1 kwasilew ccigk    6 2008-11-13 15:17 myfile
drwxrwxrwx  6 root     root  4096 2008-12-11 00:01 .snapshot
-rw-r--r--  1    65534 65534  112 2008-11-04 01:34 test_from_root@lab.txt
-rw-r--r--  1 root     root    91 2008-11-04 14:42
test_from_root@production.txt
-rw-r-----  1 amaczuga ccigk  112 2008-11-04 01:36 test_from_underling@lab.txt
-rw-r-----  1 amaczuga ccigk   91 2008-11-04 14:43
test_from_underling@production.txt
drwxrwxrwx  2 mswirydc ccigk 4096 2008-11-04 13:55 test_from_Windows
-rwxrwxrwx  1 mswirydc ccigk    4 2008-11-04 13:55 test_from_windows.txt
gklab-59-001:~# umount /mnt/


-----------------[snip]------------------

I assume then that this is the correct contents for a different directory?

What might be interesting is to do a mount of both directories and do a binary network capture of the traffic between client and server. I have to wonder if the server is returning the same filehandle for different exports on a mount request.
Comment 23 Tomasz Kepczynski 2008-12-11 11:42:22 EST
Well, I shouldn't be able to see /vol/vol1 at all (if I remember correctly server configuration does not allow me to mount it).
What actually seems to be happening is that from time to time I see one of the /vol/vol?/* directories on one or more of /vol/vol?

Is there any specific capture you would like to see or just everything directed to my host?
If I am to provide any network captures I would like either to provide it off the bugzilla (encrypted so I may need your public key), or change the bug to confidential.
Comment 24 Bug Zapper 2009-11-18 04:39:16 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 Bug Zapper 2009-12-18 02:12:15 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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