I was able to connect a few months ago by my Ubuntu 16.04 to Windows shared server driver of my institute using the «connect to server» option on a desktop panel using smb:// and the server IP address.
Now when I try to connect again it give me this error message:
Unhandled error message: Failed to mount Windows share: Connection timed out
What could be happened/changed to give this error?
Does that have to do with updating software? The samba is already at the newest version!
Melebius
10.8k8 gold badges48 silver badges75 bronze badges
asked Jun 12, 2017 at 9:35
4
The suggestions here work i.e. add in the [Global] section of the smb.conf file
client min protocol = SMB2
client max protocol = SMB2
Most of the computers on my network run Ubuntu 16.04 and the problem was getting the error message.
Unable to access location. Failed to mount Windows share: Connection Timed Out.
when connecting to a newer machine running Ubuntu 20.04. The new machine could see the network and connect to any machine on it, but not the other way around, i.e. the older machines running Ubuntu 16.04 could not access the Ubuntu 20.04 machine and responded with
Unable to access location. Failed to mount Windows share: Connection Timed Out.
answered Nov 6, 2020 at 23:06
Edit and add the below entries to /etc/samba/smb.conf, under [global]
It should look like
[global]
client min protocol = SMB3
client max protocol = SMB3
answered Sep 3, 2018 at 17:26
2
For me, I used to be able to connect to a corporate Windows share drive with Nautilus with Ubuntu 16.04, but no longer after switching to Ubuntu 18.04. Nautilus is supposed to prompt my username and password to connect to the Window share drive, but in Ubuntu 18.04, it just immediately gave the error Unable to access location. Failed to mount Windows share: Connection Timed Out. without even prompting for the username and password. I think the reason is because Ubuntu 18.04 defaults to using SMB3, which may not be compatible with the Windows share, depending on your situation.
I was able to fix it by editing sudo vi /etc/samba/smb.conf and adding client max protocol = SMB2 under the [global] section. (You could also add client min protocol = SMB2, but it wasn’t necessary for me.)
Then it prompted for my username/password, and I was able to connect to the Windows share drive.
answered Oct 21, 2019 at 18:32
wisbuckywisbucky
2,38225 silver badges17 bronze badges
There are 3 ways a Linux client can access a Linux server:
[1] By ip address directly. thunar smb://xxx.xx.xx.xxx
This is the most efficient way because it does not depend on any other process to work. In order for this to work repeatedly the server has to have a static ip address. Most if not all routers can do this for you so I would suggest looking at the documentation for your router.
[2] By its mDNS host name.
Starting with Ubuntu 17.10 the moment you install the samba package samba will automatically publish ( announce ) its presence to the rest of the network using Avahi. All Linux clients as well as all MacOS clients will see it in their file managers and can connect to it that way.
[3] NetBIOS
It’s old, complicated, convoluted, and unreliable. Microsoft itself has been trying to get rid of it for 20 years but it remains.
I’m not sure why so many Mint users have problems with [2] since it seems to work seamlessly with other distros.
I would suggest using [1]. Once you make the initial connect to the server you can bookmark it so you don’t have to use the terminal again.
If you want to pursue [2] see if you can ping the server in Mint by it’s mDNS name:
And don’t forget about the .local at the end.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
Most of the time I access my home NAS via samba shares. For increased security and performance I force it to use SMB v3 protocol. And therein lies the issue.
Whenever I tried to access my NAS from Linux Mint machine using Caja browser, I would get the same error: «Failed to mount Windows share: Connection timed out.» And it wasn’t connectivity issues as everything would work if I dropped my NAS to SMB v2. And it wasn’t unsupported feature either as Linux supports SMB3 for a while now.
It was just a case of a bit unfortunate default configuration. Albeit man pages tell client max protocol is SMB3, something simply doesn’t click. However, if one manually specifies only SMB3 is to be used, everything starts magically working.
Configuring it is easy; in /etc/samba/smb.conf, within [global], one needs to add
client min protocol = SMB3
client max protocol = SMB3Alternatively, this can also be done with the following one-liner:
$ sudo sed -i "/\[global\]/a client min protocol = SMB3nclient max protocol = SMB3" /etc/samba/smb.confOnce these settings are in, share is accessible.
for the past few weeks i’ve been battling to get my linux instances to access file shares on my windows 10 instances over the network. whether it was ubuntu, fedora, or redhat, the recent upgrades to windows 10 left my windows shares inaccessible via samba. troubleshooting was difficult as i had nothing to go on exception really ambiguous messages via the syslog («failed to mount windows share: connection timed out»). after some trial and error it all came down to an undocumented change in how windows 10 supports the smb protocol.
like most horrible troubleshooting stories, mine is filled with dead ends and false (and self inflicted) root causes.
i run a number of linux based hosts on my home network, and after installing the latest version of windows 10 insider edition, accessing network file shares on windows 10 hosts from from ubuntu simply stopped working. i immediately assumed that the insider edition had broken network sharing support, as among other things home groups were gone (i later discovered this was sadly
by design
from creators update onwards—and i was running the insider version of spring creators updates.
after configuring a non-insiders edition windows desktop to run file sharing, i realized that this was also broken. this issue must have existed for a few months before i’d noticed it.
then i turned to my primary ubuntu file server.
this is the ambiguous error i was seeing in the ubuntu network manager:
unable to access locationfailed to mount windows share: connection timed outdigging a little deeper the syslog showed a similar message with little additional context:
dbus_mount_reply: error from org.gtk.vfs.mountable.mount(): failed to mount windows share: connection timed out
assuming this was a samba file sharing issue i set about attempting to troubleshoot the networking issue by running
smbclient
and
smbtree
varying levels of logging turned on (eg «smbtree -d4») to see if there was anything going wrong in the handshake process to my windows 10 machines.
frustratingly i saw similar timeout errors while attempting to troubleshoot.
the solution (and a guess at the root cause)
after rummaging around in both the samba and windows 10 release notes for the past few version i noticed that windows 10 now offers you install a windows feature to
enable
samba 1 shares. this indicates that smb 1 isn’t supported by default:
with this little fact to go on, i had the idea that windows 10 may be blocking samba clients from negotiating at lower levels of the smb protocol.
smb 3.1.1
was released with windows 10 and windows server 2016, adding improved encryption. assuming the latest version of windows 10 has started enforcing use of higher versions of smb this sounded like a possible cause.
while this might make sense, samba is meant to support smb 3 (
man pages
), so running the latest version of samba assumes this isn’t a problem.
well, you’d assume incorrectly.
reconfiguring samba to use a minimum protocol version of smb 3, all of my issues were magically resolved.
to do this, edit your
/etc/samba/smb.conf
and under the [global] section of your samba config define the minimum version of the smb protocol to use smb 3.
[global]client min protocol = smb3alternatively, this can also be done with the following one-liner:
$ sudo sed -i "/\[global\]/a client min protocol = smb3" /etc/samba/smb.confonce these settings are saved, windows 10 shares should be accessible from your ubuntu/fedora/redhat instance and you’re off and racing again.
- Forum
- The Ubuntu Forum Community
- Ubuntu Official Flavours Support
- Networking & Wireless
- [SOLVED] mounting windows network share: «connection timed out»
-
mounting windows network share: «connection timed out»
I’m trying to mount a windows share network drive (on a university’s server) using Ubuntu 10.04. I’d like to make it a permanent mount, so I’ve added to etc/fstab, but am having problems with the following error:
Code:
mount error(110): Connection timed out Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Here’s what I’ve done so far:
My /etc/fstab has:Code:
//files.school.edu/shared /mnt/shared cifs noauto,user,username=username,uid=user,gid=group,mode=700,filemode=600 0 0
I have smbfs installed. I’ve created mnt/shared. Then from
Code:
sudo mount /mnt/shared
I type in my password, wait awhile, then get the «Connection timed out» error message above.
I’ve solved a couple of problems already to get here, but my ignorance has kept me from getting further. Any ideas? I’ll be more than happy to post some output — let me know what I should be looking at. Thanks.
-
Re: mounting windows network share: «connection timed out»
Have you tried whether you can access the resource by using the Places item on the taskbar, and then follow the dialog for ‘connect to server’ under network?
If you can get that to work, then it’s just down to detail. Otherwise there is a permissions problem to sort out (probably at the server end)Derek
-
Re: mounting windows network share: «connection timed out»
dandnsmith — thanks.
After doing what I describe above, I rebooted my computer, and the share still did not mount. However, I started it up this morning, and everything worked. Great!
If you’re looking to do something like this, try what I’ve done above. It worked for me!
bjorn
-
Re: mounting windows network share: «connection timed out»
Glad to hear it works now.
A couple of quick comments:
— you don’t need (I believe) the full samba stuff if you are not creating shares for Windows machines to access (the default stuff installed with ubuntu is enough to allow you network access to external shares).
— it’s surprising how often re-booting and waiting will ‘solve’ a problem (especially if anywhere it involves Windows servers). I’ve seen it so many times that I tell people ‘just wait, and try again’ if it ought to work, but doesn’t. There can also be questions concerning the number of network connections (and length of life) on Windows sharing.Derek
Tags for this Thread
Bookmarks
Bookmarks
Posting Permissions
James590
This person is a verified professional.
Verify your account
to enable IT peers to see that you are a professional.
thai pepper
sounds like the new user might be hitting a permission issue local to the machine
do they have mount permissions?
Was this post helpful?
thumb_up
thumb_down
This should be in Linux, I think. Definitely not under networking.
Was this post helpful?
thumb_up
thumb_down
Oh, looks like it got moved.
Was this post helpful?
thumb_up
thumb_down
It turns out that I was misled by some coincidental timing. The problem is not related to the second user being added at all. With considerable further testing I have discovered that the problem occurs on a clean Linux Mint 15 installation, logged on to the initially created administrator account.
And what I found is that the ability to ping comes and goes regularly. Ping works for 20 or 30 or 40 seconds (but NOT 25 seconds!), then it stops working for between 20 seconds and 14 minutes, with an average of about 4 minutes.
OK here’s the other big piece of information: I’m connecting this computer on the GREEN network of an IPCop Internet firewall, and the server is on the BLUE network. If I connect the computer also on the BLUE network, I don’t have this problem at all. So the problem appears to actually be at the level of the IPCop system, or the Linux interface with it. (So it IS a networking problem!)
When the computer is on the GREEN network, the failing response to ping is:
ping: unknown host mydomain.org
and the ping stops. If I start the ping while I can connect, however, the pings start out saying:
64 bytes from server5.mydomain.org (192.168.0.2): icmp_req=38 ttl=127 time=2.13 ms
and then when it shifts to «can’t connect», the responses change to this:
64 bytes from unknown.cetel-intern.local (192.168.0.2): icmp_req=39 ttl=127 time=2.12 ms
but the responses keep going. In this way, I was able to log responses over a fairly long period of time, and found my interesting on and off result above.
Note that when the ping fails, I can still ping to the physical IP address, 192.168.0.2, successfully, so it seems to be a DNS issue. But why the come-and-go nature? And why is the connection «on» for 20 or 30 or 40 seconds, but not 27 seconds? And where did this «unknown.cetel-intern.local» come from?
I’m sorry I can’t define the problem better at this point. Maybe someone can suggest some networking diagnostic commands that would shed some more light on the problem.
Was this post helpful?
thumb_up
thumb_down
Turns out it was a DNS problem. I had set DNS Primary to point to our domain controller, and DNS Secondary to point to our IPCop firewall machine. But the domain controller also pointed to IPCop as its DNS, so it think there must have been some sort of loop or race condition or something. When I set DHCP to only hand out the domain controller as Primary DNS (with no secondary DNS), it started working fine.
Was this post helpful?
thumb_up
thumb_down
I am trying to set up access to a Windows 10 share from Ubuntu 18.04.
I get the following error:
Unable to mount location
Failed to retrieve share list from server: Connection timed out
The error comes immediately as I click the Windows 10 computer name in the Files window of my Ubuntu. (For comparison, if another Windows 7 computer on the same network is not on, the error comes with a delay.)
What I did:
-
I have the following lines in my etc/samba/smb.conf per https://ubuntuforums.org/showthread.php?t=2390873&p=13764895#post13764895 :
workgroup = WORKGROUP
client max protocol = NT1
-
On Windows 10, I did Step 1 of https://websiteforstudents.com/quickly-enable-file-sharing-between-windows-10-and-ubuntu-17-04-17-10/ .
-
I checked that Windows 10 Firewall has a rule for File and Printer Sharing (SMB-In) with the following description: Inbound rule for File and Printer Sharing to allow Server Message Block transmission and reception via Named Pipes [TCP 445]. It is enabled to allow the connection. It is set for Domain, Public and Private networks. It has Protocol Type = TCP, Protocol number = 6, Local Port = Specific ports, 445. Remote port = All ports.
I do not want to use explicit IP addresses because my router assigns them dynamically.
I have another Windows 10 computer on the same network, and when I try to access it from Ubuntu, it asks for username and password. (I do not need to share it so I do not continue.)
I have another Windows 7 computer on the same network, and I can access its shares from Ubuntu. I can also access from it the shares on the Windows 10 (the one I cannot access from Ubuntu).
Many thanks for any ideas.
asked Mar 24, 2020 at 10:13
3
You must allow / force Ubuntu to use a higher protocol version for the SMB-protocol — since Windows 7 at least Microsoft retired by default the old SMB1 protocol and introduced SMB2 / SMB3 … Windows 10 extends on that principle and by standard enforces SMB3 which leaves you 2 choices :
- Enforce SMB1 (insecure according to Microsoft) on the Windows 10 machine
- Configure your Ubuntu to work with SMB3 instead of SMB1
Here is a complete description and examples https://fitzcarraldoblog.wordpress.com/2016/10/17/a-correct-method-of-configuring-samba-for-browsing-smb-shares-in-a-home-network/
According to the linked article you need to allow more ports in your firewall — as not only 445 but also 137, 138 and 139 — and probably more ports are involved (new SMB3 relies heavily on NetBios hence 137…139 )
What you wrote about the Windows 7 machine where its «working» — makes me assume that you set that one to use SMB1 — then it would be the easier step to force the Windows 10 machine to do the same … Unfortunately Linux seems unable to automatically choose the needed SMB protocol from the demands of the target machine
answered Mar 24, 2020 at 10:44
eagle275eagle275
2341 silver badge4 bronze badges
The answer of eagle275 worked for me but only after I did some additional research that I am posting here.
I enabled SMB1 on my Windows 10 machine following the first way given in https://winaero.com/blog/enable-smb1-sharig-protocol-windows-10/.
Besides enabling SMB 1.0/CIFS Client as suggested in that post, I had to enable also SMB 1.0/CIFS Server and SMB 1.0/CIFS Automatic Removal. (I did not check whether only one of these two would have been sufficient.)
In addition, I restarted not only Windows 10 machine but also the Ubuntu.
After that things worked!
answered Mar 24, 2020 at 12:56
1