I have an Ubuntu 14.04 server that has an Azure File Storage mount that auto mounts on boot via an FSTAb. To create this config, I followed the instructions in this article, and it works fine.

The issue I am having is after a while, intermittently, the mount drops. It doesn't seem to be at any particular set time, or event, the only way I know it is gone is user's complain they cannot upload files (the app persists the files on the Azure file mount). If I try to cd to the mount, my console just hangs.. if I try to do a df -h to list everything, the console also hangs. The only way I am able to get things back to normal is if I reboot the server, then everything is fine again.

I am suspicious that the connection to Azure's file storage may be intermittently dropping and coming back, but maybe the server is just not remounting when it is available again? I have a couple other (Windows) servers connected to the same file share and I do not experience this issue, so far. Has anyone else experienced this, and is there maybe a configuration that I can do to remount the share automatically if it becomes unavailable?

Any suggestions would be greatly appreciated!

  • Your system logs should have information that will help you identify the cause. Have you checked there? Also, what did Azure support say? – EEAA Jul 4 '16 at 14:51
  • Thanks, I did check the system logs trying to find anything that related to mount or anything that referenced the map path but couldn't find anything. I looked in /var/log/dmesg and /var/log/syslog Regarding Azure, I haven't opened a ticket yet since I wanted to see if it was something I can take care of first. – Sharbel Jul 4 '16 at 18:20
  • @Sharbel did u ever found a solution for this problem? Seems like we encounter the same thing :) thx – Eugene Aug 5 '16 at 14:45
  • Yes, see my answer below, hope it helps you. – Sharbel Aug 6 '16 at 9:03

I seemed to have resolved this issue by using AutoFS to mount the share instead of fstab. After making the change, we've not encountered the issue originally reported. A few days after we made the change, I did get a response from Microsoft stating this is a known issue (c/p of message below). AutoFS or Microsoft's suggestion should be a viable workaround for this issue.

Our engineers have provided the following feedback for you:

This error occurs with the Linux driver re-connects to a share when the client has been idle for an extended period of time. It disconnects and the client connection times out.

•Client is idle for an extended period of time. The Linux client sends ECHO commands periodically to keep the connection alive. •The TCP connection gets disconnected for some reason (e.g. node goes for software roll out). •The Linux client makes a new TCP connection to port 445 but sends nothing on that connection.
•After 60 seconds of idle time, SLB drops the TCP connection. •After some time, the Linux app tries to access a file and Linux sends NEGOTIATE packet which is black-holed by SLB. •The Linux client waits for 15 minutes for the TCP timeout.

Until we get a fix for this from the Linux developers the suggested workaround is to periodically access the share.

Workaround: Keep a file in the Azure File share that you write to periodically to sustain the connection and avoid getting into an idle state. This has to be write operation such as, rewriting the created/modified date on the file, otherwise you might get cached results and your operation might not trigger the connection.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.