open samba shares become unresponsive if unused for 15 minutes

Bug #1321354 reported by Martin G Miller on 2014-05-20
70
This bug affects 14 people
Affects Status Importance Assigned to Milestone
samba (Ubuntu)
High
Unassigned

Bug Description

I am running a windows file server with several shared folders. I access them from my Ubuntu machines on a gigabit ethernet local area network using nautilus and save the ones I need as bookmarks. I also have text files on the server that remain open so I can modify them during the day. I have done this succesfully for the last 4 years using Ubuntu clients 10.04, 12.04. I recently did clean installs on 3 of my office machines to 14.04. All 64 bit. Establishing the shares and saving them as bookmarks works as expected. I have the shares open across several workspaces. Leaving the shares open in their own windows will work only if I continue to use them. If I take the focus off the open window with the share for 15 minutes, the window becomes unresponsive if I attempt to do anything in it. I get the error message:
 "Oops! Something went wrong.
Unhandled error message: Software caused connection abort"

I then have to close the open window with the share which takes longer than normal to close and trying to reopen the share from nautilus also can take up to 15-20 seconds to re-open. The share will then work normally until I again stop using it for about 15 minutes, which causes a repeat of the problem. It is very consistent. Once any of the shares is made to work again, they all start working normally until the next time there is a problem.

Thinking it was a Nautilus problem, I tried using both Nemo and Thunar. They also exhibit the same problem, but instead of throwing an error message, they turn their window grey for 15-20 seconds and then start working again.

My current work around is to open a terminal and enter the command: "sudo watch smbstatus" which causes the samba server to get pinged every 2 seconds. As long as I do this, the shares all seem to work as expected again.

I have 1 Ubuntu 12.04 machine in my office that continues to handle samba shares normally.

3) What you expected to happen:
I expect open samba shares to remain responsive and usable no matter how long they are not the focus of activity.

4) What happened instead:
Instead, if the share does not remain the focus, the share becomes unresponsive and must be restarted.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: samba 2:4.1.6+dfsg-1ubuntu2.14.04.1
ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Tue May 20 11:44:47 2014
InstallationDate: Installed on 2014-05-02 (17 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions:
 nautilus 1:3.10.1-0ubuntu9
 gvfs 1.20.1-1ubuntu1
SambaClientRegression: Yes
SourcePackage: samba
UpgradeStatus: No upgrade log present (probably fresh install)

Martin G Miller (mgmiller) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in samba (Ubuntu):
status: New → Confirmed
Martin G Miller (mgmiller) wrote :

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.

Bud (vud) wrote :

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

Bud (vud) wrote :

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

yoyoma2 (sinbad-4273) wrote :

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.

yoyoma2 (sinbad-4273) wrote :

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!

Bud (vud) wrote :

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

Bud (vud) wrote :

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

Roger Preece (rwpreece) wrote :

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

Damian Yerrick (tepples) wrote :

Related question on Ask Ubuntu:

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

Roger Preece (rwpreece) wrote :

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. :)

Robie Basak (racb) on 2015-09-01
Changed in samba (Ubuntu):
importance: Undecided → High
loquens (loquens) wrote :

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)

Alex Tomko (alextomko) wrote :

This also occurs in 16.04

Alex Tomko (alextomko) wrote :

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

Alex Tomko (alextomko) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers