Latest Kernel and CIFS mount

[dmidthun]

am getting an IO error 5 when trying to mount CIFS share on 4.13.0-26 (generic) since upgrading. Has anyone seen or heard this and what might be the cause?

mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)


Downgrading the Kernel to 4.10.0-42 on boot does not generate the same error.


Thanks,
Dan

[Kraveez]

Same here. I can no longer mount 2 NAS shares using FSTAB with kernel 4.13.0-26-generic, 18.2.
Content of FSTAB:

Code: Select all

//NAS/share /mnt/share cifs credentials=/root/.creds,iocharset=utf8,sec=ntlm, 0 0

I get the following errors:

Code: Select all

tail -f /var/log/kern.log
kernel: [74712.645361] CIFS VFS: Unable to select appropriate authentication method!
kernel: [74712.645365] CIFS VFS: Send error in SessSetup = -22
kernel: [74712.645387] CIFS VFS: cifs_mount failed w/return code = -2

I tried specifying a cifs version as per some suggestion as follows:

Code: Select all

//NAS/share /mnt/share cifs credentials=/root/.creds,iocharset=utf8,sec=ntlm,vers=2.1 0 0

with no luck. Any ideas?

[spsimmons64]

Running into the same issue. Please advise.

[altair4]

Linux Kernel 4.13 changed the default CIFS smb version from vers=1.0 to vers=3.0.

So if your CIFS mounted before that kernel version and does not now you need to force the mount to vers=1.0by adding it to the list of options. For example:

//NAS/share /mnt/share cifs credentials=/root/.creds,iocharset=utf8,sec=ntlm,vers=1.0 0 0

[riffbiker]

I have just experienced the same issue, and agree with altair4. The only reason I upgraded Mint Cinnamon 18.3 to Kernel 4.13.0-31 is because it is allegedly patched to mitigate Meltdown / Spectre (a recently announced hypothetical vulnerability affecting most computer processors of the last twenty years - search the web for it). Previously I was running Kernel 4.10.0-42 with a perfectly stable system.

The moment I rebooted to Kernel 4.13.0-31, AND the released today 4.13.0-32, the CIFS shares to my networked NAS server failed. Investigation has proven that previous Kernels default to CIFS 1.0 and my NAS Server is only capable of CIFS 1.0. Adding the TAG vers=1.0 to FSTAB as altair4 kindly offers does indeed instruct the Kernel to use CIFS 1.0 - however all is NOT well!

I use OpenOffice (have uninstalled all LibreOffice components in their entirety including appropriate dependencies - my system has been running thus for three years and is rock solid). There is some strange behaviour in OpenOffice Calc - the spreadsheet application - but not with writer (the word processor) or any other program I have tried (including playing music and video from the NAS server - all that is fine).

OpenOffice Calc with Kernel 4.13.x and FSTAB TAG vers=1.0 to Force CIFS 1.0
-------------------------------------------------------------------------------------------
Opening a saved Calc spreadsheet on the NAS is intermittent, often causing an OpenOffice General Input / Output Error. Saving an opened spreadsheet might also cause an Input / Output error. Repeatedly trying to open the spreadsheet will usually cause it to finally open, however closing it and trying to open a second spreadsheet is again intermittent. Finally managing to open one such spreadsheet and KEEPING IT OPEN, perhaps minimising it to the Panel, allows other spreadsheets on the NAS to open seamlessly as expected.

Opening first a Writer document and keeping it open, blocks opening a Calc spreadsheet.

If the Desktop should crash or there be any other interruption, OpenOffice Recovery does not successfully connect to the NAS to recover the document, such that unsaved changes might be lost.

Work Arounds
----------------
1. Create an OpenOffice Calc empty spreadsheet and save it to the NAS. Open it from the NAS and minimise it to the Panel. This seems to keep the 'pipe' open such that other spreadsheets open and save correctly.
2. Save work in the document regularly.
3. Copy the spreadsheet to the Desktop (local storage) while it is being worked on and back it up to the NAS when work is completed.
4. Revert to Kernel 4.10.0-42 (which is NOT patched to mitigate Meltdown / Spectre) - this works perfectly!

Explanation
--------------
The behaviour is caused by the FILE LOCKING mechanism in OpenOffice, which is designed to lock an open file such that a second or other user can only open the same file as read-only. I hypothesise that using Kernel 4.13.x (CIFS default v 3.0) and the vers=1.0 TAG in FSTAB, is slowing the read/write access to the NAS over CIFS by a few milliseconds, tricking OpenOffice into thinking the file is already open when trying to open it. The OpenOffice forum, not relating to this CIFS cause, makes reference to editing an OpenOffice system file to disable File Locking, but that of itself poses other hazards.

Whether or not this same behaviour applies to LibreOffice, I do not know and don't feel like testing, however suspect the behaviour will be the same as the issue is in the CIFS timing rather than the program. For what it's worth, I actually do not like LibreOffice, preferring OpenOffice as it seems more 'professional'. I would far prefer LibreOffice WAS NOT bundled with Linux Mint hooked so deeply into the system, allowing the user to choose an Office package for themselves.

Caveat: I mentioned I remove LibreOffice and all its dependencies - this is not straightforward and some dependencies affect other programs which also are removed, and then some dependencies have to be re-installed for the correct functioning of other areas of Linux Mint. Unless you know what you are doing, do not uninstall LibreOffice. I do not wish to elaborate on this.

REQUEST TO CLEM AND MINT DEVELOPERS
-------------------------------------------------
It is possible to get Ubuntu to address this Kernel 4.13.x issue, perhaps modifying the inbuilt Kernel cifs-utils or whatever to rectify it? Alternatively, restoring the default CIFS version to 1.0 such that a user has to invoke CIFS 3.0 and not the other way around. FYI - I use a quality ZyXel NAS Server and spoke with ZyXel yesterday. Their default is still CIFS 1.0 and they themselves are checking to see whether they can implement CIFS 3.0 on certain latest models.

Riffbiker
Computer Engineer

[altair4]

I'll have to look at the file locking issue vs kernel level as I have not seen anything about this before.

You might want to amend your cifs mount statement to include the nobrl option to see if that fixes things:
nobrl = no byte range locking

Alternatively, restoring the default CIFS version to 1.0 such that a user has to invoke CIFS 3.0 and not the other way around.

Mint and Ubuntu are not in a position to change that. CIFS is part of the Linux kernel. That's where the change took place. It's really just following where things are at: At the host level Windows, macOS, and Linux by default all use SMB3 at the highest level. Combine that with OS's like Win10 that disable SMB1 on new builds and CIFS has no choice but to adjust it's defaults.

The only things that have not moved on are these network devices.

[riffbiker]

You are a star, altair4!

Adding the FSTAB TAG nobrl completely cures the CIFS 'out of tolerance timing' file-locking issue. With nobrl added, OpenOffice Calc files on the NAS server open exactly as they should with or without an OpenOffice Writer document on the NAS already open. If a second instance of the same file is opened from the NAS on the local machine, the file opens, but upon attempting to save warns that other users have altered the file and changes will be overwritten. I have not tested file locking from other than the local machine.

All is good at time of writing. (FYI the TAG nolock also corrects the CIFS problem, but I agree nobrl is the better option).

For the benefit of others: my FSTAB TAGS entry for the CIFS share is now:
cifs credentials=/home/yourusername/.credentials,vers=1.0,nobrl,rw,nosuid,nodev,noexec,uid=1000 0 0

Change 'yourusername' for your own user name... and don't forget to make a .credentials file

Many thanks, altair4

Riffbiker
Computer Engineer