Network and Storage Protocols

Can't copy large files to a CIFS Share



I got the error shown below whenever I will try to copy anything over 1GB. Any idea why?

Title: Network Error

Message: There is a problem accessing X:\foldername

                 Make sure you are connected to the network and try again.





You can use robocopy to migrate CIFS data.

A quick start guide to use robocopy to migrate CIFS data can be found in the below link,


If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.


Hi Hariprak,

I'm not migrating the data. I'm asking why I can't copy anything over 1GB to one of my CIFS share.



Did you disabled the CIFS protocol on the interface (options).

Might also an issue with the tcpip packet size.


CIFS is not disabled, otherwise I couldn't copy files smaller than 1GB.


I'm having the same problem, but only on one share that's running on the first controller.  Our other two shares on the second controller work fine.  The settings are all the same, the only difference i've noticed is that when copying the large file, the share that fails is actually copying twice as fast as the other two shares that work.


A couple of questions...

what version of SMB are you running?  1, 2, 2.1, or 3?

What OS is the file on? 

are you trying to copy this file over an onboard 1G port or is it a card?


Hi jlee,

          In the options list, it says 2 enabled is off, so i'm guessing 1. 

          I actually just tried copying a 4GB file from Windows Server 2003 and it was successful, from 2008 R2 and Windows 7, it fails.

          Onboard 1G ports.


Interesting.  This issue seems to reside with SMB 2.0.  Windows 2003 uses 1.0.  2008R2 and Windows 7 all use 2.0. 

The other shares you are using...what OS's are they using to copy?


Same thing I thought.  However, I can copy the same file to the other 2 shares from Windows 7 and Server 2008R2.  I would expect them to fail also, unless the problem is with the second controller.

The two working shares are on the same controller, the one that doesn't work is running on the other controller.


What version of DOT are you running?  What controller type?


My brain is blanking... DOT?

It's an IBM N6210 running Data ONTAP release 8.1.2P4 7-Mode. 

It seems to be a wannabe Netapp by IBM but running the Netapp code.  I don't like it really, just got handed over to me.


DOT - DataOntap

The IBM N6210 adds a bit of complexity to it...

can you post the settings for the CIFS volume?


cifs.LMCompatibilityLevel    1

cifs.W2K_password_change     off

cifs.W2K_password_change_interval 4w

cifs.W2K_password_change_within 3600h

cifs.audit.account_mgmt_events.enable off


cifs.audit.autosave.file.limit 0

cifs.audit.autosave.onsize.enable off

cifs.audit.autosave.onsize.threshold 75%

cifs.audit.autosave.ontime.enable off

cifs.audit.autosave.ontime.interval 1d

cifs.audit.enable            off

cifs.audit.file_access_events.enable on


cifs.audit.liveview.enable   off

cifs.audit.logon_events.enable on

cifs.audit.logsize           1048576

cifs.audit.nfs.enable        off


cifs.audit.saveas            /etc/log/adtlog.evt

cifs.bypass_traverse_checking on

cifs.client.dup-detection    ip-address


cifs.enable_share_browsing   on

cifs.gpo.enable              off

cifs.gpo.trace.enable        off

cifs.grant_implicit_exe_perms off



cifs.home_dirs_public_for_admin on

cifs.idle_timeout            900

cifs.ipv6.enable             off

cifs.max_mpx                 253

cifs.ms_snapshot_mode        xp


cifs.netbios_over_tcp.enable on

cifs.nfs_root_ignore_acl     off

cifs.oplocks.enable          on

cifs.oplocks.opendelta       0

cifs.per_client_stats.enable on


cifs.perm_check_ro_del_ok    off

cifs.perm_check_use_gid      on

cifs.preserve_unix_security  off

cifs.restrict_anonymous      0

cifs.restrict_anonymous.enable off

cifs.rpcfd_timeout           0

cifs.save_case               on



cifs.show_dotfiles           on

cifs.show_snapshot           off

cifs.shutdown_msg_level      2

cifs.sidcache.enable         on

cifs.sidcache.lifetime       1440

cifs.signing.enable          off

cifs.smb2.enable             off

cifs.smb2.signing.required   off

cifs.smb2_1.branch_cache.enable off

cifs.smb2_1.branch_cache.hash_time_out 3600       (value might be overwritten in takeover)

cifs.snapshot_file_folding.enable off

cifs.symlinks.cycleguard     on

cifs.symlinks.enable         on

cifs.trace_dc_connection     off

cifs.trace_login             off

cifs.universal_nested_groups.enable on

cifs.widelink.ttl            10m


Hey, has this been resolved?



It seems to be a SMB problem with ONTAP 8. I tried to copy a big file from a NetApp filer with ONTAP 8 to my local Win 7 PC with windows explorer. The copy starts with 2 MB/s or less. Within a few minutes the copy slows down to < 1MB/s. Only reading is a problem, writing works fine. Also reading from a Windows Server 2003/2008 works fine. Seems to be a smb problem with ONTAP 8.

The same situation on a NetApp filer with an ONTAP 7.3.6 works fine.

Our workaround is:

Run Cmd with

netsh interface tcp set global autotuning=disabled

reboot the win 7 computer.



I have faced similar problem and after analyzing the packet traces I am able to resolve this issue,


One of the possible reason for this :- 

Clustered Data ONTAP has an option called fastpath. This allows the SVM to respond to a client without taking time to check the routing table. There are certain items that will not use fastpath, such as icmp. If you do not have a default route configured, icmp (ping), when initiated from the SVM, will fail. 

In this case, the issue occurs as soon as there is packet loss on the wire. This is more likely to be seen with larger file transfers. The client is writing data and a packet does not reach the SVM. The client keeps sending data. The SVM receives these other packets, but will send a DupAck. This is to let the client know to resend the lost packet. The issue occurs because a DupAck does not use fastpath. So it will check the routing table, not find a route and drop the DupAck. The client will eventually start trying to retransmit the last non-acked packet, until it reaches a timeout and stops the stream.  


Two methods to confirm:

  • Check if the default route is not configured for the Vserver: network route show -vserver <vserver>
    cluster::> network route show -vserver svm1 (8.2 command is network routing-groups route show)
    There are no entries matching your query.
  • Ping a working IP that is on a different subnet than the LIFs on the cluster:
    net ping -lif <svm1_lif1> -vserver <vserver> -destination <destination>
  1. Add a default route:
    network route create -vserver <vserver> -destination -gateway <gateway ip>  
    Note: Data ONTAP 8.2.x requires a routing-group. For more information, see article 3013489: Ethernet routing in Clustered Data ONTAP 8.0 and 8.1
  2. Confirm the route was added:
    cluster::> network route show -vserver <vserver> 
    Vserver             Destination     Gateway         Metric
    ------------------- --------------- --------------- ------
                     <gateway ip>     20                        <<<<<<< The new route is added

You can also refer KB which I found later -->





Pranay Gupta