[Resolved] SMB/Samba timeout change ??

[tovian]

I'm running a Windows-7 (Pro) machine as a file-server. I have several Windows machines and one Mint machine permanently connected to my LAN. The Mint machine is running 17.2 with all current updates. It has worked correctly - using Samba to share files to/from the Windows (and other Mint) machines - including the file-server - ever since I set this up (several years ago). I never had any timeout issues between Linux (SMB) and Windows until a couple of months ago. Now, I'm having to restart the server service on the Windows file-server at least once per day because the Mint machine loses its connection to the Windows machine. And, it's only the Mint machine. When the connection breaks all the Windows machines can still access the file-server without problems. I've tried restarting SMB on the Mint machine, but that does not restore the connection.

It seems that something has changed in SMB/Samba. I've tried searching for problems like this on the net, and I've found a lot, but none of those problems (that I have found so far) seem to be the same issue I'm having.

Any thoughts/ideas/suggestions ?

TIA !!

[altair4]

I've never experienced your issue but it's probably because I don't use samba this way. I connect to a share when needed and unmount it when I'm done.

How are you currently connecting to the Windows File Server?

Do you connect to it from your Linux file manager or perhaps Gigolo? Or do you do a cifs mount?

You might consider a CIFS mount specifiaclly tuned to a Win7 machine:

** Starting with this HowTo: On Demand CIFS Mounting of Shares
** Make it specific to a Win7 server. For example:

Code: Select all

//server/share /media/Share cifs username=nnn,password=ppp,noauto,user,uid=1000,vers=2.1 0 0

The Linux file manager, gigolo, and CIFS use SMB1 when connecting to a share and SMB1 is considered "chatty". Win7 can use SMBv2.1 which is a fair improvement but CIFS must be told to use it. vers=2.1 tells it to use version 2.1 of SMB.

[tovian]

@ altair4 - Thank you for the information. Unfortunately (for me) some of it is beyond my understanding.

I do not think I have done anything exotic. On the MInt machine I have defined the files/folders I want to share in the smb.conf file in the /etc/samba folder. No problems. When I enter the machine IPAddress in any other machine I see the items I have shared. This still works perfectly.

On the Windows machine (used as a file-server):
1. I share folders on my network by accessing/modifying properties for each folder I want to share (standard method).
2. I set permissions using groups rather than user-id. That way I can add user-ids at will, and simply put them in the group (or not). I use explicit shares and permissions - none of the "Windows Homegroup" fantasy-world crap.
3. I use the same user-id & password (for myself) on all my machines.
4. I DO NOT do any explicit mounts (on Windows or Mint). I access all shares (wherever they reside) using a shortcut to the share's URL, or I simply type the target machine IPAddress in the address bar of the (Windows or Mint) file manager. I do saves and deletes the same way. None of my machines has to know if another one is Windows, Linux, or something else. All my IP's are static, and I know them without even having to think (makes it a lot easier when I connect a client machine to my LAN and need to retrieve some piece of software from one of my machines).

ALL OF THIS has worked perfectly for several years. I have set this up, re-done it, modified it, and so forth so many times I can do it in my sleep. I've done essentially the same thing at many of my client homes/businesses.

It's just that for approximately the last two months my (main) Mint machine has bee "disconnecting" from the Windows file-server on a daily basis. I DID NOT change anything in my networking when this started happening (still haven't).

I was going to upload a pic of the error message, but it has not occurred yet (today). I will capture it the next time it happens.

[altair4]

If you are doing everything by ip address you have another option:

** Edit /etc/samba/smb.conf

** Under the workgroup = WORKGROUP line add a new line:

Code: Select all

client max protocol = SMB3

** Restart smbd sudo service smbd restartor if you are connected to many shares reboot the box.

Now you don't have to change how you are accessing the shares.

[tovian]

Thank you for your suggestion.

I have implemented the change.

Please give me a summary of what this option does so I don't have to do a lot more research.

[altair4]

In my previous post I mentioned that the samba client process ( which the file manager, gvfs, and gigolo use ) by default use SMB1 to make a connection. It's "chatty" and can cause disconnects and slow file transfers when connecting to a more current samba server.

THere's two ways out of this:

[1] A CIFS mount specifying a newer version of SMB.

[2] Or within smb.conf which controls the kind of samba client process the file manager and gvfs use.

When a samba client initially connects to a samba server it negotiates which version of SMB to use. It will negotiate between two limits: client min protocol and client max protocol. As I said above the max level by default is SMB1 but Win7 uses SMBv2.1. By setting the max to SMB3 Linux will choose the best version to use with every Windows ever made including Win10.

[tovian]

Thank you for that information.

So far all is working well again - no disconnects today. I will let it run for another day or two then close this thread if there are no more incidents.

[tovian]

Have not had the problem for several days so I am closing this thread.

I found what may have been a loose ethernet cable plugged in the machine so that could have been causing a problem - but I would have thought that either the cable works or not and re-starting the (Windows server) service definitely would not fix a bad cable/connection.

I'm satisfied that the settings change (from above) fixed the problem.

Thank you, again !!