如何正常处理Samba共享下线?

我有一个Ubuntu 16.04 LTS Web服务器,通过Samba挂载Windows文件服务器。 Web服务器需要能够偶尔执行与该服务器上的文件交互的任务。 但是,最近我们与Windows文件服务器中断,导致Web服务器开始performance得非常糟糕。 我希望挂载closures会简单地导致尝试与该文件夹交互的命令立即失败(使我们能够快速捕获和处理exception),但相反,看起来与挂载的交互发生得非常缓慢

这里是/ etc / fstab中用于装载共享的条目:

//<Windows server hostname>/TPA /mnt/TPA cifs username=tasker,password=<redacted>,domain=<our domain>,sec=ntlm,iocharset=utf8,sec=ntlm 0 0 

所谓“缓慢”,我的意思是说,如果我做了ls /mnt ,命令需要大概30秒才能完成,然后给我下面的消息:

 user@server:/mnt$ ls ls: cannot access 'TPA': Host is down 

在networking应用程序本身也可以看到这种缓慢。 如果可能的话,我希望能够设置Web应用程序来检测共享是否closures,并优雅地处理,但是我不希望每个请求都花费30秒。 有没有一种方法可以configuration的东西,这样可以更好地处理?

为了使事情更加复杂,Web应用程序实际上在一个Docker容器中,该容器添加了一个指向/mnt ,这可能使事情变得更糟,尽pipe我想如果我用主机解决问题,那么容器应该有希望同样落伍。

任何build议将不胜感激!

编辑:我会补充说,暂时,我们已经卸载了违规山,并从fstab注释掉了这条线,这似乎使它“高兴”,但理想情况下,我宁愿一个解决scheme不是那么手动。

只是一些想法…

我不确定如何testing/mnt在访问时如何回应。 但我有如何更准确地预测它的想法。

您可以使用smbclientnmap尝试连接到服务器。 或者用cron在后台运行一些东西……看起来不错,在/ mnt下的文件 – 这样在遇到超时时不会减慢速度。 如果有任何testing失败,请告诉Web应用程序。

test -d /mnt && echo true在文件服务器closures时也失败…如果有帮助的话。 但是你需要等待它超时。

smbclient //host/share -Uuser password 如果服务器closuressmbclient //host/share -Uuser password 将几乎立即返回,所以不会减慢速度。 nmap也是如此,但并不是真的想要login到文件服务器。

我希望这有一些帮助。