Bug 4192 - mount_cifs.so no such file, FC6
mount_cifs.so no such file, FC6
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-27 12:03 UTC by Akemi Yagi
Modified: 2009-05-14 15:39 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Akemi Yagi 2006-10-27 12:03:01 UTC
I am running Fedora Core 6 and getting this error:

open_mount: (mount):cannot open mount module cifs (/usr/lib/autofs/mount_cifs.so: cannot open shared object file: No such file or directory)

Is this something that should be reported to RedHat/Fedora?

Incidentally, since I updated kernel to 2.6.18 on FC5 (and 2.6.18 of a fresh install of FC6), I have been experiencing system lockups.  Wonder if this is related to the problem descibed in Bug#4180 (and the relavant RedHat bug in there).  At least in FC6, the crash seems to occur when symlnks are created on Desktop that point to samba shares which are set up to be auto-mounted.

Akemi
Comment 1 Steve French 2006-11-01 19:44:27 UTC
No the fc6 bug was a wrong return code on readdir (ls) of large directories on cifs mounts - although fc6 has the wrong default i/o size for cifs (4K instead of 16K) it is harmless (although slower) in all other cases (other than readdir)

Did your autofs case work for earlier kernels?
Comment 2 Steve French 2006-11-01 19:46:49 UTC
Any ideas about who knows about autofs and how to construct such a module?

AFAIK - cifs does not have such a module (as nfs and a few local fs do) so can't handle autofs - although ought to be easy to build one (autofs/mount_cifs.so) if we could find some examples
Comment 3 Akemi Yagi 2006-11-01 21:14:45 UTC
(In reply to comment #1)

> Did your autofs case work for earlier kernels?

Yes, I and others in my area have been mounting windows shares through autofs under FC4, FC5, CentOS4 and SuSE10.x.  Even with the above error in FC6, mounting still takes place and I can access remote shares.  The problem is the system lockups I started having after I upgraded the kernel from 2.6.17 to 2.6.18 on the FC5 machine.  On the same machine, I did a fresh install of FC6 and the crash problem persisted.  Then I filed a bug report at:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211672

It is possible that my system crash problem is not directly related to cifs, but whenever I do a cifs mount, the system locks up anywhere between immediately and a few minutes later.

Akemi

Comment 4 Steve French 2006-11-01 21:53:47 UTC
autofs version 5 source does appear to have an auto.smb which supports cifs (mounts with type -t cifs) - not exactly sure how this works but can not be too hard to figure out.
Comment 5 Steve French 2006-11-01 22:03:41 UTC
Looking more carefully at the autofs modules, it looks like the generic module should be able to handle cifs already.

Could you give a quick easy example of how to setup autofs to mount cifs - I could then fire up a vmware session with fc6 in it and try the experiment here and debug it.

What is the autofs version (5?)
Comment 6 Akemi Yagi 2006-11-02 01:06:56 UTC
(In reply to comment #5)
> Looking more carefully at the autofs modules, it looks like the generic module
> should be able to handle cifs already.
> 
> Could you give a quick easy example of how to setup autofs to mount cifs - I
> could then fire up a vmware session with fc6 in it and try the experiment here
> and debug it.

In the autofs map file, add this line:

deneb  -fstype=cifs,rw,noperm,user=zzzzz,pass=xxxxxx,workgroup=yyyy ://deneb/sharename

Please note that this is one line.  deneb is the remote Windows box.

> What is the autofs version (5?)

CentOS4 4.1.3
FC5 4.1.4
FC6 5.0.1
Comment 7 Akemi Yagi 2006-11-08 17:03:35 UTC
Someone reported seemingly the same problem to RedHat's bugzilla.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622

At least, I am not the only one having this system lockup.  It is happening on two different machines in my office, and both are quite stable as far as I do not cifs mount.  The kernels up to 2.6.17 did not have this problem.

Akemi
Comment 8 Steve French 2006-11-16 16:41:16 UTC
Let me know if there is more to fix (other than utimes)
Comment 9 Steve French 2006-11-16 16:42:22 UTC
Ignore the last comment (pasted to wrong defect)
Comment 10 Akemi Yagi 2006-11-21 09:05:04 UTC
Just found this post on the kernel maillist:

Subject:      Kernel panic in cifs_revalidate
From:         "Chakri n" <chakriin5@gmail.com>
Newsgroups:   gmane.linux.kernel
Date:         Tue, 21 Nov 2006 00:24:40 -0800

Hi,

I am seeing a kernel panic in cifs module. It seems to be a result of
invalid inode entry in dentry for the file it is trying to validate.

The inode->i_ino is set zero and inode->i_mapping is set to NULL in
the inode pointer in the dentry (0xdf8ea200) structure. I went through
the cifs code and could not find any valid case that could trigger
this situation. Is there any case which can lead to this situation?

0xed47fe70 0xc0133b30 filemap_fdatawait+0x20 (0x0, 0xe0e1c780, 0x0,
0xf5b35000, 0x0)
                               kernel .text 0xc0100000 0xc0133b10 0xc0133bc0
0xed47feb8 0xf8b49855 [cifs]cifs_revalidate+0x225 (0xdf8ea200)
                               cifs .text 0xf8b27060 0xf8b49630 0xf8b49af0
0xed47fec4 0xf8b3ec71 [cifs]cifs_d_revalidate+0x11 (0xdf8ea200, 0x0, 0xef47a031)
                               cifs .text 0xf8b27060 0xf8b3ec60 0xf8b3ec7d
0xed47fed8 0xc0151c03 cached_lookup+0x43 (0xe8e03a00, 0xed47fefc, 0x0,
0x1, 0xe7f5b0f8)
                               kernel .text 0xc0100000 0xc0151bc0 0xc0151c20
0xed47ff18 0xc01522a8 link_path_walk+0x3e8
                               kernel .text 0xc0100000 0xc0151ec0 0xc0152610
0xed47ff20 0xc0152629 path_walk+0x19 (0x8002, 0x8003, 0x83141a0)
                               kernel .text 0xc0100000 0xc0152610 0xc0152630
0xed47ff34 0xc015280a path_lookup+0x3a (0x0, 0x0, 0x2, 0x0, 0x0)
                               kernel .text 0xc0100000 0xc01527d0 0xc0152810
0xed47ff64 0xc0152d3a open_namei+0x6a (0xef47a000, 0x8003, 0x0,
0xed47ff7c, 0xe8e03a00)
                               kernel .text 0xc0100000 0xc0152cd0 0xc0153260
0xed47ffa0 0xc01448b1 filp_open+0x41 (0xef47a000, 0x8002, 0x0,
0xed47e000, 0x8002)
                               kernel .text 0xc0100000 0xc0144870 0xc01448e0
0xed47ffbc 0xc0144ca1 sys_open+0x51 (0x83141a0, 0x8002, 0x0, 0x8002, 0x83141a0)

Thanks
--Chakri
Comment 11 Steve French 2009-05-14 15:24:15 UTC
Since we haven't seen other reports of this, sounds like it is likely to be fixed.  Will leave it open for a few weeks in case someone is still seeing this
Comment 12 Akemi Yagi 2009-05-14 15:39:23 UTC
(In reply to comment #11)
> Since we haven't seen other reports of this, sounds like it is likely to be
> fixed.  Will leave it open for a few weeks in case someone is still seeing this

The kernel panic problem has been resolved (thanks to you, Steve and Shirish) as logged in this Red Hat bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=224359

The other (original) issue of strange message "open_mount: (mount):cannot open mount module cifs (/usr/lib/autofs/mount_cifs.so: cannot open shared object file: No such file or directory)" does not occur in the current RHEL/CentOS.  So, this can be regarded resolved.

Akemi