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
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?
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
(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
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.
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?)
(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
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
Let me know if there is more to fix (other than utimes)
Ignore the last comment (pasted to wrong defect)
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
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
(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