New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coreos 1520.6.0 CIFS mount fails #2204

Closed
Sudneo opened this Issue Oct 18, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@Sudneo

Sudneo commented Oct 18, 2017

Issue Report

Bug

After upgraded coreos version (automatically updated), mounting a samba share with mount.cifs fails.
The error thrown from mount.cifs is 'directory not found', but the actual error in dmesg is
[ 31.573539] CIFS VFS: could not allocate crypto cmac-aes
[ 31.573541] CIFS VFS: generate_key: crypto alloc failed
[ 31.574417] CIFS VFS: Send error in SessSetup = -2
[ 31.574798] CIFS VFS: cifs_mount failed w/return code = -2

I read somewhere it might be related to not having md5 kernel module loaded, but I am not really sure.

The mounting was working for months in the same way.

Container Linux Version

The version is 1520.6.0 , from stable channel

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1520.6.0
VERSION_ID=1520.6.0
BUILD_ID=2017-10-12-0349
PRETTY_NAME="Container Linux by CoreOS 1520.6.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

CoreOs is running in VirtualBox. The same behavior happened both using Vbox in Windows and in Linux.

Expected Behavior

mount.cifs should be able to mount a shared directory, when the correct address, user and options are passed to it.

Actual Behavior

After prompting for the user's password, the mount fails with

Oct 18 08:09:08 Daniele mount.cifs[2405]: mount error(2): No such file or directory
Oct 18 08:09:08 Daniele mount.cifs[2405]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

From dmesg

[   31.573539] CIFS VFS: could not allocate crypto cmac-aes
[   31.573541] CIFS VFS: generate_key: crypto alloc failed
[   31.574417] CIFS VFS: Send error in SessSetup = -2
[   31.574798] CIFS VFS: cifs_mount failed w/return code = -2

Reproduction Steps

  1. Have coreos installed in Virtualbox
  2. Download mount.cifs , for example, as done here https://github.com/so0k/mount.cifs_copy
  3. Share a directory from the host with samba (windows or Linux)
  4. runsudo mount.cifs //ho.st.ip.addr/nameshare /existing/local/dir -o rw,user=USER,uid=500,gid=500,cache=none (Or other combination of option, had the same result even with simply username and nothing else.)

Other Information

There are no many references of similar bugs in the past, but I found a similar one in rear/rear#149 and here https://www.linuxquestions.org/questions/linux-kernel-70/cannot-load-md5-ko-module-911608/ . They are both related to completely different systems, but maybe the root is similar.

@alexismeneses

This comment has been minimized.

Show comment
Hide comment
@alexismeneses

alexismeneses Oct 18, 2017

Hello,

Got the same problem here.

To be more precise, it is no longer possible to mount SMB 3.0 shares in CoreOS Container Linux. However mounting the CIFS shares using protocol version 2.1 or lower is still working (i.e. using -o vers=2.1 in mount.cifs) if the server allows it. This is not the case of Azure Fileshare used outside the same Azure Region for example.

It seems to appear since CoreOS Container Linux 1520.5.0 (is it related to the migration to kernel 4.13?).

Reading the source code of CIFS support in the kernel shows that SMB3 require cmac(aes) which is provided by CMAC crypto module . This kernel module (cmac.ko located in /usr/lib64/modules/*/kernel/crypto/cmac.ko) has disappeared in latest CoreOS Container Linux releases.

alexismeneses commented Oct 18, 2017

Hello,

Got the same problem here.

To be more precise, it is no longer possible to mount SMB 3.0 shares in CoreOS Container Linux. However mounting the CIFS shares using protocol version 2.1 or lower is still working (i.e. using -o vers=2.1 in mount.cifs) if the server allows it. This is not the case of Azure Fileshare used outside the same Azure Region for example.

It seems to appear since CoreOS Container Linux 1520.5.0 (is it related to the migration to kernel 4.13?).

Reading the source code of CIFS support in the kernel shows that SMB3 require cmac(aes) which is provided by CMAC crypto module . This kernel module (cmac.ko located in /usr/lib64/modules/*/kernel/crypto/cmac.ko) has disappeared in latest CoreOS Container Linux releases.

@Sudneo

This comment has been minimized.

Show comment
Hide comment
@Sudneo

Sudneo Oct 18, 2017

Hello,

Thanks for the details, it was very helpful to get which module is missing.

I can also confirm that overriding the version to 2.1 the mount works, despite we were using 3.02 to solve some specific issue with node module installing.

I also supposed it was related to kernel change from version 1520.5.0 , but I can't confirm, since I didn't have the chance to test this specific version.

Sudneo commented Oct 18, 2017

Hello,

Thanks for the details, it was very helpful to get which module is missing.

I can also confirm that overriding the version to 2.1 the mount works, despite we were using 3.02 to solve some specific issue with node module installing.

I also supposed it was related to kernel change from version 1520.5.0 , but I can't confirm, since I didn't have the chance to test this specific version.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Oct 18, 2017

Member

Confirmed. A couple module dependencies were lost in the update from 4.12 to 4.13. We'll get a fix queued up for the next stable update.

Member

bgilbert commented Oct 18, 2017

Confirmed. A couple module dependencies were lost in the update from 4.12 to 4.13. We'll get a fix queued up for the next stable update.

@zq-david-wang

This comment has been minimized.

Show comment
Hide comment
@zq-david-wang

zq-david-wang Oct 19, 2017

@bgilbert
I am running 1465.8.0, and today(Just now) when I try to update via "sudo systemctl start update-engine", it shows that no update available, is it because of this issue that 1520.6.0 not showup in my update?

 <request protocol="3.0" version="update_engine-0.4.2" updaterversion="update_engine-0.4.2" installsource="scheduler" ismachine="1">
     <os version="Chateau" platform="CoreOS" sp="1465.8.0_x86_64"></os>
     <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="1465.8.0" track="stable" bootid="{53be9f36-7d73-47e7-b677-bdda5645d8fe}" oem="" oemversion="" alephversion="1465.8.0" machineid="3f4d1c03b33f40f8bea7c94be8c6f004" lang="en-US" board="amd64-usr" hardware_class="" delta_okay="false" >
         <ping active="1"></ping>
         <updatecheck></updatecheck>
         <event eventtype="3" eventresult="2" previousversion="0.0.0.0"></event>
     </app>
 </request>

 <response protocol="3.0" server="update.core-os.net">
  <daystart elapsed_seconds="0"></daystart>
  <app appid="e96281a6-d1af-4bde-9a0a-97b76e56dc57" status="ok">
   <updatecheck status="noupdate"></updatecheck>
  </app>
 </response>

zq-david-wang commented Oct 19, 2017

@bgilbert
I am running 1465.8.0, and today(Just now) when I try to update via "sudo systemctl start update-engine", it shows that no update available, is it because of this issue that 1520.6.0 not showup in my update?

 <request protocol="3.0" version="update_engine-0.4.2" updaterversion="update_engine-0.4.2" installsource="scheduler" ismachine="1">
     <os version="Chateau" platform="CoreOS" sp="1465.8.0_x86_64"></os>
     <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="1465.8.0" track="stable" bootid="{53be9f36-7d73-47e7-b677-bdda5645d8fe}" oem="" oemversion="" alephversion="1465.8.0" machineid="3f4d1c03b33f40f8bea7c94be8c6f004" lang="en-US" board="amd64-usr" hardware_class="" delta_okay="false" >
         <ping active="1"></ping>
         <updatecheck></updatecheck>
         <event eventtype="3" eventresult="2" previousversion="0.0.0.0"></event>
     </app>
 </request>

 <response protocol="3.0" server="update.core-os.net">
  <daystart elapsed_seconds="0"></daystart>
  <app appid="e96281a6-d1af-4bde-9a0a-97b76e56dc57" status="ok">
   <updatecheck status="noupdate"></updatecheck>
  </app>
 </response>
@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Oct 19, 2017

Member

@zq-david-wang Starting update-engine.service will not immediately initiate an update. Once update_engine is running, see this page for instructions on forcing an update. If that isn't working for you, please open a new bug.

Member

bgilbert commented Oct 19, 2017

@zq-david-wang Starting update-engine.service will not immediately initiate an update. Once update_engine is running, see this page for instructions on forcing an update. If that isn't working for you, please open a new bug.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert
Member

bgilbert commented Oct 19, 2017

Fixed by coreos/linux#99.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Oct 20, 2017

Member

Merged in all branches.

Member

bgilbert commented Oct 20, 2017

Merged in all branches.

@zq-david-wang

This comment has been minimized.

Show comment
Hide comment
@zq-david-wang

zq-david-wang Oct 23, 2017

@bgilbert thx for the information. And I can upgrade to "stable (1520.6.0)" successfully now.

zq-david-wang commented Oct 23, 2017

@bgilbert thx for the information. And I can upgrade to "stable (1520.6.0)" successfully now.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Oct 24, 2017

Member

This will be fixed in stable 1520.7.0, beta 1548.3.0, and alpha 1562.2.0, due shortly. Thanks for reporting.

Member

bgilbert commented Oct 24, 2017

This will be fixed in stable 1520.7.0, beta 1548.3.0, and alpha 1562.2.0, due shortly. Thanks for reporting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment