ONTAP Discussions
ONTAP Discussions
Hello,
after the ONTAP update from 9.7P5 to 9.7P11 on 19.02.2021, it happens with us on a Linux FTP server that Windows mounts can no longer be created or break again after a short time - then they can not be remounted. There are always different shares.
Volumes/shares are definitely present and could also be mapped under Windows. - Errors on the NetApp cluster are not present in the event log.
Before the ONTAP update everything worked fine.
The affected Linux-Server - a virtual machine - uses SLES 12 SP 5 (SUSE Linux Enterprise Server 12 (x86_64)).
Here's an example:
ftpserv1:~ # mount -t cifs -o vers=3.0,username=HERE_WAS_THE_USERNAME_WRITTEN,password=HERE_WAS_THE_PWD_WRITTEN //FSDXXXXX/Produktion/XFirm/XFirmV/Program_Data/FBXX-FBYY-Kontoauszuege/sic /ftptrans/StAYY/XFIRM-KONTOAUSZUEGE
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
dmesg-Message
[11472.498939] CIFS: Attempting to mount //FSDEXXXXX/Produktion/XFirm/XFirmV/Program_Data/FBXX-FBYY-Kontoauszuege/sic
[11472.518538] CIFS VFS: cifs_mount failed w/return code = -2
/var/log/messages
2021-02-22T13:52:27.182532+01:00 ftpserv1 kernel: [11472.498939] CIFS: Attempting to mount //FSDXXXXX/Produktion/XFirm/XFirmV/Program_Data/FBXX-FBYY-Kontoauszuege/sic
2021-02-22T13:52:27.202512+01:00 ftpserv1 kernel: [11472.518538] CIFS VFS: cifs_mount failed w/return code = -2
However, it is possible that the above mount will be successful an hour later.
Any idea?
Thank You. Best Regards
Michael
Solved! See The Solution
Hello,
thank you very much for the information.
I have also opened a case and also already received an answer:
The error is on the Linux side where the OS does not close the expired CIFS session and continues to use it.
This used to work because ONTAP had a bug prior to 9.7P8 and did not enforce rejecting expired sessions. NetApp fixed this in 9.7P8 and now the Linux bug becomes obvious.
Link to Knowledge Base Article:
Our Linux admin has now applied a recent patch and we hope that the problem is fixed (a recent SLES 15 cannot be used on the system for various reasons e.g. reiserFS).
Regards
Michael
It could be upgrade related bug, but it could also be external (different DC it started using, time/NTP disparity between the client/storage/DC etc...) you can of course open a case to help you troubleshooting and to confirm if there's a known issue.
As for the troubleshooting - any information on the NetApp log at the time of the mount? (event log show).
I'd also try the full workflow for permission troubleshot including sectrace (form 9.6 available also in the GUI): https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_Troubleshoot_Client_Permission_Issues_in_ONTAP_9
and packet trace
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_capture_packet_traces_(tcpdump)_on_ONTAP_9.2__systems
Hello,
thank you very much for the information.
I have also opened a case and also already received an answer:
The error is on the Linux side where the OS does not close the expired CIFS session and continues to use it.
This used to work because ONTAP had a bug prior to 9.7P8 and did not enforce rejecting expired sessions. NetApp fixed this in 9.7P8 and now the Linux bug becomes obvious.
Link to Knowledge Base Article:
Our Linux admin has now applied a recent patch and we hope that the problem is fixed (a recent SLES 15 cannot be used on the system for various reasons e.g. reiserFS).
Regards
Michael
Thanks for this. Helped me too 🙂