[SOLVED] mount.cifs Cannot allocate memory OR Remote I/O error after data transfer

czezz · 06-18-2014, 10:26 AM

I have started to experience a very odd problem with mount.cifs.
In fact it might be not a problem with mount.cifs itself but with Windows 7 machine which actually share resource/dir. However its difficult for me to figure out that. (Its also difficult to choose right sub-forum for this case).
It is odd that it has started to be happening like this only since yesterday.

Here is a story:
I have 2 Linux boxes - Slackware 13.37 and latest Ubuntu 14.04 plus Windows 7 box.
On Windows 7 I share 1 directory using Windows SHARE allowing to my user have full access / permission (RW)

From time to time I mount this shared DIR on one of my Linux boxes to transfer some files to Windows box.
Starting since yesterday I have started to experience following problem:
After coping some portion of data, I am not able to copy another portion of data or even ls on mounted dir.
If I try to re-mount the share I got following errors (note its different for each system):

Slackware:

Code:

root@slacx:~#  mount.cifs //164.48.174.216/backup /mnt/zip/ -o user=user1
Password:
mount error(12): Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Ubuntu:

Code:

root@ubuntu:~# mount.cifs //164.48.174.216/backup /mnt/zip/ -o user=user1
Password for user1@//164.48.174.216/backup:
mount error(121): Remote I/O error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Rebooting Linux box does not help but rebooting Windows box does help BUT only for 1st copy operation.
I would say it is Windows problem but then it makes me wonder why it was working OK for so long time and all of the sudden it stopped.

Any ideas here?

dijetlo · 06-20-2014, 04:32 AM

Try to mount the slice with the "noserverino" option. You may not be able to follow hardlinks, but since you're pushing instead of pulling, that shouldn't matter.
From the above referenced Man page

Quote:

INODE NUMBERS
When Unix Extensions are enabled, we use the actual inode number provided by the server in response to the POSIX calls as
an inode number.

When Unix Extensions are disabled and "serverino" mount option is enabled there is no way to get the server inode number.
The client typically maps the server-assigned "UniqueID" onto an inode number.

Note that the UniqueID is a different value from the server inode number. The UniqueID value is unique over the scope of
the entire server and is often greater than 2 power 32. This value often makes programs that are not compiled with LFS
(Large File Support), to trigger a glibc EOVERFLOW error as this won´t fit in the target structure field. It is strongly
recommended to compile your programs with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this problem. You can
also use "noserverino" mount option to generate inode numbers smaller than 2 power 32 on the client. But you may not be
able to detect hardlinks properly.

czezz · 09-30-2014, 05:02 AM

If anyone is experiencing similar problem then here is solution:
http://boinst.wordpress.com/2012/03/...windows-share/

This is Windows problem and following registry values need to be changed:

Code:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache - set it to 1
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size - set it to 3

Restart service "Server"

GreyGnome · 02-29-2016, 03:26 PM

Quote:

Originally Posted by czezz

If anyone is experiencing similar problem then here is solution:
http://boinst.wordpress.com/2012/03/...windows-share/

This is Windows problem and following registry values need to be changed:

Code:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache - set it to 1
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size - set it to 3

Restart service "Server"

I had problems with both Windows and Linux machines, and found this link: http://winhlp.com/node/40

Essentially, for posterity, they say, "Here is the offending registry value:

Code:

    HKEY_LOCAL_MACHINE
     \SYSTEM
      \CurrentControlSet
       \Services
        \LanmanServer
         \Parameters
    IRPStackSize DWORD 0x0000000f (15)

Check for the presence of the value named IRPStackSize. If it doesn't exist, create it as type DWORD and make sure you have the capitalization absolutely correct (5 upper case, 7 lower case characters), because the system strangely seems to depend on that. Make sure also that you haven't by mistake added a leading or trailing space..."

The issue, at least in our case, is that Win 7 Pro is not initially optimized as a server but that's how we want to use it.