Hide Forgot
Description of problem: can create a file, delete the same file, append to that file...but after initial creation we cannot overwrite the file. Version-Release number of selected component (if applicable): samba-client-3.0.33-3.38.el5_8 (5.8) samba-client 3.6.6 (5.9) How reproducible: always Steps to Reproduce: 1. create share on netapp filer OnTap 8.2p2 cluster mode Not DFS share ntfs security permissions at share level ntfs set to default (full control) 2. mount share; touch file 3. attempt to overwrite file /etc/fstab: //fsg6000cnc/quip05 /mnt/quip_test cifs username=webadmin,password=*****,domain=xxx.net,uid=web,gid=web 0 0 [root@wqui001cnc ~]# df -hPv Filesystem Size Used Avail Use% Mounted on ... //fsg6000cnc/quip05 55T 25M 55T 1% /mnt/quip_test [root@wqui001cnc ~]# touch /mnt/quip_test/me [root@wqui001cnc ~]# echo "testing" > /mnt/quip_test/me -bash: /mnt/quip_test/me: Input/output error [root@wqui001cnc ~]# echo "testing" >> /mnt/quip_test/me [root@wqui001cnc ~]# cat /mnt/quip_test/me testing Actual results: Expected results: Additional info: This works fine on RHEL 6 (samba-client 3.6.9)
Can you upgrade to samba3x and try again?
Please note that after upgrading to samba3x you cannot downgrade to the old samba packages anymore, because the on-disk tdb files used by samba are upgrade automatically during the upgrade. To be on the safe side it is recommended to backup the tdb files before upgrading. More details can be found in the Release Notes.
This happens using both samba3x-client-3.5.10-0.108.el5_8 (RHEL 5.8) and 3.6.6 (RHEL 5.9). It does not happen on RHEL 6, where mount.cifs is in cifs-utils. It also does not happen with either RHEL 5 or RHEL 6 when mounting an HA Netapp Ontap CIFS share - it only happens with clustered Ontap.
Jeff, Sachin, can one you have a look at this ticket? Sounds like a kernel issue.
Hello Donald, I have tried this on my test machine and it works fine for me. Can you please provide a tcpdump taken with the command on the client tcpdump -w out.pcap -s 0 host fsg6000cnc -w out.pcap -> Write tcpdump to a file called out.pcap -s 0 -> Capture complete packets. host fsg6000cnc -> filter to capture packets to and from fsg6000cnc which is the server. You will need to run this command in a terminal while you run the test again on a different terminal. Once the test has been completed, please stop the tcpdump with ctrl-C. Can you also provide me with the kernel version you are using. Could you also please open a support ticket and point them to this bz since that is the proper channel for a support request. Sachin Prabhu
ahh sorry, Didn't see that this is a support case.
Sachin, were you trying it with clustered OnTap (not HA/7-mode)? The customer has tried 8.2p2 and 8.2p4 with the same results. This case is also being worked on by NetApp.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in the last planned RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.
email from Netapp Jan. 28: ... - Our engineering team has found the issue as we discussed and has been able to successfully reproduce the error. - They have tested a fix in the code that has had successful results. - From one of our engineer’s notes “in samba source code to see where the error is coming from and how the client handles the error. I see why STATUS_INVALID_INFO_CLASS and ERRunknownlevel (124) errors work with samba client, but not STATUS_UNSUCCESSFUL.” - They have discussed that the fix does work with Older versions of the Samba client and that this should possibly be the return code we use going forward as it does not seem to affect any of the newer versions of the Samba client either. - We are currently doing further regression testing but as of now I cannot give a date on when the fix will be implemented in either a patch or major revision of the code. So we will have to wait a bit longer while they work the details out. ... So we are waiting on a patch/fix from Netapp and will see if that resolves the issue.
This issue was resolved by the customer upgrading their NetApp clustered OnTap software version to 8.2P4D6.