open samba shares become unresponsive if unused for 15 minutes

Status changed to 'Confirmed' because the bug affects multiple users.

I have since built a new file server which runs Ubuntu 14.04. All Samba shares to it function normally. The problem is with Samba and WIndows XP. I don't know if it affects all versions of Windows or just XP 32 bit that I was using. I now have the 2 Windows programs that I can't get away from running in a VM on the Ubuntu server.

I also have this issue... at the office with a Windows 2003 Server, and at home with two Buffalo link stations. Initial secure connect is quick and painless, but after about 15 minutes, even with docs/files open but inactive... the connection is lost and multiple refreshes are necessary to re-attain a working connection. If a change is made to an open idle document/spreadsheet or even a paused video in Totem is restarted, the window grays and the rotating circle is present. I have multiple directory maps to the same server, and when one is forced to refresh and become active again, the others do not. They each have to go through the same lengthy refresh period in order to be accessible. At times, the listing of the directory in the side panel tree is removed, and a root refresh is required to get it back.
I do nothing but praise the reliability of Ubuntu with fellow co-workers (who are all on Windows with its set of problems) but this problem is a major issue.
Thanks for elevating this to a confirmed status, and hopefully it will be assigned soon!
Thanks
Bud

PS... The error message window I continually receive says:

Could not display "smb://xxxxxxx/yyyy/".
Error: Software caused connection abort
Please select another viewer and try again.

Occurs with: Files 3.10.1 AND Nemo 1.8.4

Thanks,
Bud

Happens with ubuntu 14.04 LTS mounting shares from Windows 7. Just mounting the share with 'gedit smb://mywinserver/mypath/myfile' with no file manager at all reproduces the bug.

Microsoft servers drop idle connections after 15 minutes. This behavior can be disabled by this command as administrator (details: http://support.microsoft.com/kb/297684).

net config server /autodisconnect:-1

Alternatively, adding the following script to the gnome startup applications keeps the connections alive.

#!/bin/bash
while true
do
    ls /run/user/`id -u`/gvfs/smb-share:* &> /dev/null
    sleep 600
done

Thanks yoyoma2 - the script you provided works a treat!

If Windows drops idle connections in 15 minutes, then why do all previous versions of Ubuntu work on the same server without error? I am in the same boat with Martin... been using Ubuntu for years. 14.04 has this problem everywhere I have used it in a network environment; different machines and different servers. Surprised more people are not writing in.
Thanks, Bud

14.04 - 32bit also... same problem.
Bud

My experience is the same as Bud (vud) (see entries #4 and #5).

Please fix as soon as possible. I have other colleagues experiencing this as well. It's very annoying and time consuming not to mention the loss of data and work if a file is open and modified when the connection is dropped by the Windows server.

Windows Server administrators will not want to disable the "autodisconnect" as it's a feature intended to reduce server resource usage.

Thanks,
Roger

Related question on Ask Ubuntu:

How to fix a “Software caused connection abort” error in Ubuntu 14.04?
https://askubuntu.com/q/450206/232993

Importance = Undecided? How can a regression that causes data loss be "undecided"?! This bug also wastes a lot of time and resources. When it happens your file manager hangs indefinitely and you have to "end the process" not just close the file manager and reopen it. You actually have to open your system monitor, find your file manager, and then end it's process. The file manager is a major part of the desktop. Killing/ending it can cause other instability that may also cost the loss of data if other applications hang leaving you unable to save your work.

I love you guys but wow.

Linux is way beyond the "toy os" phase. it's used everywhere by not only developers but desktop users that are tired of the high cost of ownership with "the other OS".

With Ubuntu and Linux Mint you are up and running right out of the box. That word needs to be spread much more widely and through more than just word-of-mouth.

If my job didn't drive me 24/7 I'd get involved and help with this stuff, which is what I plan to do when I retire. :)

This behaviour appeared for me first time after upgrade to Ubuntu 17.04. Several versions before (all from 14.04) there had no such problem. And now after some idle time I can see constant network load (down ~300 kB/s, up ~450 kB/s, see screenshot in attachemenet).

Unmounting helps (but sometimes umount hangs for several minutes before unmounting)

This also occurs in 16.04

I have to reboot my computer - unmounting or trying to end process hangs for hours.

This happens every 15 minutes for me if I do not have a cron job sending files to each of my shares.

For the question why the very old release didn't show the problem I'd assume they held something as an open file. This is usually not needed and often fixed after some time, but a behaviour like e.g. keeping the root of the mount open would explain why it wasn't breaking there as the windows definition says:

"... An idle connection is defined as a connection which has no existing open handles (no open files, directories, search contexts, etc.), and no pending operation. ..."

So other than configuring windows to not drop this (as outlined in comment #7) I wonder what one can do.
I can't speak for the apps that use it like Nautilus that was reported, but a "normal" local share shouldn't care much. The Apps might fall into a loop of try-to-refresh-fail-..., but if just mounted there should not be anything.

One of the last reports mentioned ongoing traffic, it might be worth to use iptraf to check what connection that is. Is it to Samba, if so use wireshark to track down what. If the former assumptions on the auto-disconnect are true then we might see reconnect attempts or something like that.

[1] holds some background on various timeouts in windows cifs shares. [2] confirms this applies at least up to windows 7.

[1]: https://blogs.msdn.microsoft.com/openspecification/2013/03/19/cifs-and-smb-timeouts-in-windows/
[2]: https://support.microsoft.com/en-us/help/297684/mapped-drive-connection-to-network-share-may-be-lost