help - can't stat() cifs file system
Subsystems (2)
To whom it may concern,
I am using linux kernel 2.6.32-220.4.1.el6.x86_64 (RHEL6) and cifs version 4.8.1. Using a mount point (/mnt/tmp), we are able to read/write to our Windows directories. Occasionally, a user will kill a job that is writing to these directories. When this happens, it corrupts the mount point somehow and we get a permission denied error when we do an “ls”.
If I do an “lsof” and grep for the path, I get a message:
WARNING: can’t stat() cifs file system /mnt/tmp
It seems that if I am able to successfully unmount all of these mount points, that I can do a “mount –a” and recover.
However, how can I avoid this problem in the first place (besides having the user not kill jobs)? It seems like this is something a user should be able to do without bringing down the mount points.
Thank you in advance,
Mark
Quoted 15 lines · On Fri, 2 Mar 2012 14:29:44 -0800 "Mark Christiansen"…
To whom it may concern,
I am using linux kernel 2.6.32-220.4.1.el6.x86_64 (RHEL6) and cifs version 4.8.1. Using a mount point (
/mnt/tmp), we are able to read/write to our Windows directories. Occasionally, a user will kill a job that is writing to these directories. When this happens, it corrupts the mount point somehow and we get a permission denied error when we do an “ls”.If I do an “lsof” and grep for the path, I get a message:
WARNING: can’t
stat()cifs file system/mnt/tmpIt seems that if I am able to successfully unmount all of these mount points, that I can do a “mount –a” and recover.
Quoted 9 lines
However, how can I avoid this problem in the first place (besides having the user not kill jobs)? It seems like this is something a user should be able to do without bringing down the mount points.
Thank you in advance,
Mark
That certainly sounds like a bug, but we'll need to do some work to track down the cause.
What would be ideal would be for you to open a RH support case so we could work with you to track down the cause and a reproducer. Alternately, you could open a bug at bugzilla.redhat.com and work with it there if you're not able to open cases with our support people. If you do the latter, be sure to cc me on the bug and I'll see if I can help.
Thanks,
Signature · 1 line
Jeff Layton <[email protected]>
A message that is not in the archive (sent off-list or not yet received): 20120303063558.2a1885c3-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org
Hi Jeff,
Since I don't have RedHat support, I opened a bug through bugzilla.redhat.com. The bug number is 800082. I see that it was assigned to you.
Thank you for future correspondence while troubleshooting this bug. I can coordinate with the end user experiencing this bug, if you think it is helpful for reproduction. Also, if you need log files, etc, I am happy to pass them along.
Best regards,
Mark Christiansen
University of Washington
Cardiovascular Health Research Unit
(206) 287-2768
-----Original Message-----
From: Jeff Layton [mailto:[email protected]]
Sent: Saturday, March 03, 2012 3:36 AM
To: [email protected]
Cc: [email protected]
Subject: Re: help - can't stat() cifs file system
Quoted 15 lines · On Fri, 2 Mar 2012 14:29:44 -0800 "Mark Christiansen"…
To whom it may concern,
I am using linux kernel 2.6.32-220.4.1.el6.x86_64 (RHEL6) and cifs
version 4.8.1. Using a mount point (/mnt/tmp), we are able to
read/write to our Windows directories. Occasionally, a user will kill
a job that is writing to these directories. When this happens, it
corrupts the mount point somehow and we get a permission denied error when we do an “ls”.If I do an “lsof” and grep for the path, I get a message:
WARNING: can’t
stat()cifs file system/mnt/tmpIt seems that if I am able to successfully unmount all of these mount points, that I can do a “mount –a” and recover.
Quoted 9 lines
However, how can I avoid this problem in the first place (besides having the user not kill jobs)? It seems like this is something a user should be able to do without bringing down the mount points.
Thank you in advance,
Mark
That certainly sounds like a bug, but we'll need to do some work to track down the cause.
What would be ideal would be for you to open a RH support case so we could work with you to track down the cause and a reproducer.
Alternately, you could open a bug at bugzilla.redhat.com and work with it there if you're not able to open cases with our support people. If you do the latter, be sure to cc me on the bug and I'll see if I can help.
Thanks,
--
Jeff Layton <[email protected]>