我有一个Ubuntu的14.04服务器，有一个Azure文件存储安装自动挂载启动通过FSTAb。 要创build这个configuration， 我按照这篇文章中的说明 ，它工作正常。
我遇到的问题在一段时间之后，间歇性地下降。 它似乎没有在任何特定的时间，或事件，我知道这是消失的唯一方法是用户抱怨他们不能上传文件（该应用程序保持在Azure文件装载的文件）。 如果我尝试cd到挂载，我的控制台挂起..如果我试图做一个df -h列出一切，控制台也挂起。 我能够恢复正常的唯一方法是如果我重新启动服务器，那么一切都很好。
我怀疑与Azure文件存储的连接可能会间歇性地丢失并返回，但是当服务器再次可用时，服务器可能不会重新安装？ 我有一些其他（Windows）服务器连接到相同的文件共享，到目前为止我没有遇到这个问题。 有没有其他人经历过这种情况，有没有可能的configuration，我可以做自动重新挂载共享，如果它变得不可用？
任何build议将不胜感激！
我似乎已经通过使用AutoFS挂载共享而不是fstab来解决此问题。 改变之后，我们还没有遇到原来报道的问题。 在我们做出改变的几天后，我确实收到了微软的回应，声称这是一个已知的问题（下面的c / p消息）。 对于这个问题，AutoFS或微软的build议应该是一个可行的解决方法。
我们的工程师为您提供以下反馈：
当客户端长时间闲置时，Linux驱动程序重新连接到共享时会发生此错误。 它断开连接，客户端连接超时。
•客户端闲置很长一段时间。 Linux客户端周期性地发送ECHO命令以保持连接的活跃。 •由于某种原因，TCP连接断开连接（例如节点进行软件转出）。 •Linux客户端与端口445build立新的TCP连接，但在该连接上不发送任何内容。
•空闲60秒后，SLB断开TCP连接。 •一段时间后，Linux应用程序尝试访问文件，Linux发送SLB黑洞的NEGOTIATE包。 •Linux客户机等待15分钟以等待TCP超时。在我们从Linux开发人员那里得到一个解决scheme之前，build议的解决方法是定期访问共享。
解决方法：将您写入的Azure文件共享中的文件定期保留以保持连接，并避免进入空闲状态。 这必须是写入操作，例如，重新创build/修改文件的date，否则你可能会得到caching的结果，你的操作可能不会触发连接。