Network and Storage Protocols
Network and Storage Protocols
Hi,
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.
Thanks.
Hi,
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,
Thanks
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.
thanks
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.extension
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.allowed_users
cifs.audit.liveview.enable off
cifs.audit.logon_events.enable on
cifs.audit.logsize 1048576
cifs.audit.nfs.enable off
cifs.audit.nfs.filter.filename
cifs.audit.saveas /etc/log/adtlog.evt
cifs.bypass_traverse_checking on
cifs.client.dup-detection ip-address
cifs.comment
cifs.enable_share_browsing on
cifs.gpo.enable off
cifs.gpo.trace.enable off
cifs.grant_implicit_exe_perms off
cifs.guest_account
cifs.home_dir_namestyle
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_aliases
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.perfmon.allowed_users
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.scopeid
cifs.search_domains
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:
You can also refer KB which I found later --> https://kb.netapp.com/support/s/article/unable-to-write-or-copy-large-files-to-the-svm
Regards,
Pranay Gupta