mount.cifs error: CIFS VFS: could not allocate crypto hmacmd5

[berndg]

hi,

after successful 'rear -v mkbackup" and burning ISO and booting from CD and after login, I try to 'mount.cifs' and getting error message: mount error(2) no such file or directory ???

my system is openSUSE 12.1 in out of ISO installation with rear-1.13.0-13.noarch.rpm installed.

regards,
bernd

[dagwieers]

Is it possible to try the same with the latest snapshot release ? You can use the OpenSUSE RPM packages for this too from the Snapshot repository. It is likely going to fail in the same way, but I'd like to be sure as the upcoming 1.14 will have lots of improvements.

[berndg]

I'am frustrated,

same with snapshot version and all other versions.
same at openSUSE 11.4 in out of ISO installation.
'rear -v mkbackup' works fine with cifs share, after booting from CD and try to mount.cifs with same share gives error: mount error(2) no such file or directory ?
this sucks really, I spend now many days and CDs and no resolution, I have no further idea.

dmesg gives:
CIFS VFS: could not allocate crypto hmacmd5
CIFS VFS: could not setup hash structures rc -2
CIFS VFS: cifs_mount failed w/return code = -2

[dagwieers]

Your issue seems to be related to this message CIFS VFS: could not allocate crypto hmacmd5.

To me that suggests that CIFS (a kernel module) is lacking some crypto module, likely tcrypt.

Have you tried doing: modprobe tcrypt before doing the restore ?
If that does not make a difference, you could also try doing: modprobe -v --all -t crypto.

From some reports about this exact error, it might also be related to anonymous (guest) CIFS access. As a test, you might want to test using a username/password (see the documentation on how to configure Relax-and-Recover to use CIFS credentials).

Please do report back.

[berndg]

I do not use guest account, I have created a user 'rear' with password access.
I will try your suggestion and report back.

[dagwieers]

Strike the comment about tcrypt and the crypto modules, it had references to md5 and hmac, but it's a test module so it does not offer anything. As far as I can tell the crypto stuff used in cifs does not come from kernel infrastructure.

One option is to see if you can provide a different sec= option to your mount command line, but if all else fail we may have to wait until we have OpenSUSE test infrastructure to mimic this behavior an debug ourselves.

[berndg]

• solved

the kernel-crypto-md5 module is not loaded and is missing in rescue image, the solution for openSUSE is to preload the module on startup in /etc/sysconfig/kernel and it will be included in rescue image and mount.cifs works.

[gdha]

what is exactly the kernel module name? Use lsmod | grep md5 and paste the output. In our prep phase we have to make sure this kernel module is copied to the rescue image.

[berndg]

the module is md5, /lib/modules/{kernel-version}/kernel/crypto/md5.ko

[dagwieers]

I have two concerns:

• RHEL (and others) include this functionality in the kernel, not as a separate module, so a solution is specific to one or more distributions
• If cifs.ko depends on md5.ko, it should have a dependency set (seems to be a bug/oversight in the kernel)

I would take this up with the distribution. Can you open a ticket with OpenSUSE asking why the cifs.ko module does not depend on md5.ko ? Why they don't compile it as part of the kernel ? And how does OpenSUSE make sure it gets loaded when a user on OpenSUSE needs mount.cifs ? With this I mean, "how does the distribution handle this lack of dependencies", rather than "how does the user work around the problem".

I would hate to see us implement something specific for OpenSUSE if the problem is in fact a kernel issue (which might already be fixed with newer kernels and/or which might affect other distributions too).

If we really need a solution that covers everything, I would suggest to include the crypto-drivers as part if the stock drivers we include (much like storage and network).

[berndg]

there is no problem with mount.cifs in openSUSE in 11.4 or 12.1 when needed, this works fine.
the problem is, that rear does not include the md5 module in rescue image, when it was not loaded at the moment of the creation of the rescue image.
for rear, I would prefer your last suggestion, to include the crypto-drivers as part of the stock modules.

[dagwieers]

@berndg There is no problem because OpenSUSE (somehow) preloads md5.ko. The real problem is that cifs.ko does not depend on md5.ko and thus gets not loaded automatically. Maybe there is a good reason for not having this dependency and that's maybe why Red Hat decided to compile it into the kernel.

Just look at:

[dag@moria rear]$ grep cifs /lib/modules/2.6.32-279.5.2.el6.x86_64/modules.dep
kernel/fs/cifs/cifs.ko:

What is apparent from the 'modules.dep' file is that there is no single general-purpose module that depends on crypto modules, so I think there is a purpose in not having these dependencies.

In the meantime I added some code to include all crypto modules (about 1MB on my system) on the rescue image, but that does not guarantee md5.ko is being loaded (yet).

[dagwieers]

I need to reopen this issue as the modules are not automatically loaded, yet.

[berndg]

openSUSE does not preload md5 module, it is only loaded when needed acc. use of mount.cifs and corresponding answer of cifs share.
also rear must not load it automatically but it must be available for loading therefore it must be included and referenced in rescue image .
best choice would be that all crypto modules are be available for loading.

[dagwieers]

Ok, I misunderstood. The above fix should help in that case. If this fix does not solve your issue, feel free to reopen the issue.

Thanks for your help in getting it fixed !

[gdha]

just a last comment about this:
we do have a script usr/share/rear/rescue/NETFS/default/39_check_crypto_modules.sh which is supposed to be taken care of the CIFS crypto stuff. If the script becomes obsolete now, we better remove it, right?

[dagwieers]

Ouch, I was not aware there was a special case already implemented. The question begs, should we make this specific to the CIFS case, or not. Is a 1MB increase in the size of the rescue image (in all cases) acceptable or not. I am undecided.

The other question is, why did this particular script fail ? It is clear that the current fix covers more cases.

Let's reopen to get to the bottom of this :-)

[berndg]

further tests reconfirm my statement.
local.conf:
MODULES=("${MODULES[@]}" 'md5')
#MODULES_LOAD=()
when useing mount.cifs md5 is loaded from cifs but it must be included in rescue image!

[schlomo]

IMHO we should automatically include these kinds of modules and not make
users include them manually. Some helper modules don't have dependencies
because they are loaded by demand, so we should just have a list of such
things.

[gdha]

I'm in favour of removing the existing script usr/share/rear/rescue/NETFS/default/39_check_crypto_modules.sh and include all modules (if I'm not mistaken this is standard behavior in v1.14 already).
Do we have an agreement?

[schlomo]

+1

[dagwieers]

Yes, I agree too.

[dagwieers]

OK, this should already have been fixed. So closing it now. Please reopen if for some reason the included fixes do not work correctly.