Mount error 115 operation now in progress cifs centos 7

CentOS

The Community ENTerprise Operating System

Mounting CIFS shares in fstab

Post by ek123 » 2019/11/04 20:15:13

I’ve got 2 boxes running centos8, one providing samba shares to local network. These shares are accessible from windows machines without password prompting. Also, I can mount them without issue using the following syntax and I am not prompted for a password.

mount.cifs //ipaddress/share /mnt/share -o guest

However, when I attempt to mount through fstab I am unable to get the share connected; either I am prompted for password and hit enter to move on (that will work) or I am not prompted and the mount fails with

mount error(115): Operation now in progress
Refer to mount.cifs(8) manual page.

I have been digging around trying to find an option to make this work and I am stuck. Any ideas would be appreciated.

These are the 3 entries in my fstab as I’ve been tweaking and attempting other solutions which all behave similarly.

[stor]
path = /mnt/stor1
writable = yes
browsable = yes
guest ok = yes
guest only = no
create mode = 0777
directory mode = 0777

[stor2]
path = /mnt/stor2
writable = yes
browsable = yes
guest ok = yes
guest only = yes
create mode = 0777
directory mode = 0777

[stor3]
path = /mnt/stor3
writable = yes
browsable = yes
read only = no
guest ok = yes

Thanks in advance

Re: Mounting CIFS shares in fstab

Post by TrevorH » 2019/11/04 20:18:20

Re: Mounting CIFS shares in fstab

Post by ek123 » 2019/11/04 22:07:51

Re: Mounting CIFS shares in fstab

Post by TrevorH » 2019/11/04 22:21:00

Re: Mounting CIFS shares in fstab

Post by BShT » 2019/11/05 12:20:02

try credentials=/etc/smbcredentials in fstab then

# cat /etc/smbcredentials
username=youruser
password=yourpass

Re: Mounting CIFS shares in fstab

Post by ek123 » 2019/11/05 14:39:43

Well, I thought it was corrected with the path change and was able to mount everything but after a restart I’m seeing the error again.

fstab entries (I’ve tried many variations on these, but these are current)
//192.168.254.25/plex /mnt/plex/storage cifs vers=1.0,user=guest,password= 0 0
//192.168.254.25/plex2 /mnt/plex/storage2 cifs user=guest,password= 0 0

Error seen upon mount attempt
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

dmesg
[ 1010.144200] CIFS VFS: Error connecting to socket. Aborting operation.
[ 1010.144210] CIFS VFS: cifs_mount failed w/return code = -115
[ 1010.146774] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 1020.383355] CIFS VFS: Error connecting to socket. Aborting operation.
[ 1020.383366] CIFS VFS: cifs_mount failed w/return code = -115

I added vers=1.0 to the first entry based off of the dmesg output but I’m still seeing both fail to mount. I’ve read specifying the version should help, but didn’t have any luck with that so far but I’m probably just missing something.

I’ve not tried to use a credentials file, attempting to use these as anonymous shares. Should I need the credentials file?

**update**
$ sudo mount -t cifs -o username=guest,password= //192.168.254.25/plex /mnt/plex/storage
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
$ smbclient -L 192.168.254.25
Connection to 192.168.254.25 failed (Error NT_STATUS_IO_TIMEOUT)

smb.conf
[global]
workgroup = ELYSIUM
security = user
log level = 1
passdb backend = tdbsam

printing = cups
printcap name = cups
load printers = yes
cups options = raw

unix charset = UTF-8
dos charset = CP932
map to guest = Bad User
username map = /etc/samba/smbusers
guest account = nobody

[plex]
path = /mnt/plex-storage
writable = yes
browsable = yes
guest ok = yes
guest only = no
create mode = 0777
directory mode = 0777

[plex2]
path = /mnt/plex-storage2
writable = yes
browsable = yes
guest ok = yes
guest only = yes
create mode = 0777
directory mode = 0777

Источник

mount error(115): Operation now in progress (azure file mount won’t work due to 445 port blocked) #1592

What happened:
A pod unable to attach or mount volumes

The error:
Warning FailedMount 15s kubelet, aks-nodepool1-* (combined from similar events): MountVolume.SetUp failed for volume «pvc-» : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: —description=Kubernetes transient mount for /var/lib/kubelet/pods/ —scope — mount -t cifs -o cache=none,dir_mode=0777,file_mode=0777,gid=1000,mfsymlinks,nobrl,uid=1000,username=,password=,vers=3.0 //.file.core.windows.net/kubernetes-dynamic-pvc- /var/lib/kubelet/pods/1*/volumes/kubernetes.io

azure-file/pvc-*
Output: Running scope as unit run-*.scope.
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:
Storage and Nodes are in the same region.
The nodes are in a Virtual Network
We haven’t enabled TCP 445 in our firewall, it is not clear from the documentation if is required.
The documentation we followed:
https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic#required-ports-and-addresses-for-aks-clusters
The troubleshoot documentation:
https://docs.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-linux-file-connection-problems

Environment:

• Kubernetes version:
  Client Version: version.Info
  Server Version: version.Info
• Size of cluster: 3
• General description of workloads in the cluster: Python Flask
• Others: Node OS Ubuntu 16.04

The text was updated successfully, but these errors were encountered:

Источник

Mount error 115 operation now in progress cifs centos 7

Edit: Point of clarification — In the examples below, you’ll notice I use a domain name of ‘lamasondufeu’. I always make use of a domain name on mixed networks in order to enforce Windows Workgroup naming consistency. By default, Samba will use the domain name of the computer it’s running on as the ‘Windows Workgroup’ unless you explicitly provide one in smb.conf. Also by default, WinXP always uses ‘workgroup’ as it’s value for ‘Windows Workgroup’.

All computers which expect to talk to each other using Windows networking need to either be in the same Workgroup or you need to explicitly which workgroups they are allowed to talk to. Selecting a specific domain name for your network and using that as your Windows Workgroup name makes mixed networks much easier to adminster. Also, it’s considered bad security practice to leave the Windows Workgroup name at it’s default value so this is something you want to change anyway.

It’s always good policy on multi-computer local networks to pick your own domain name and stick with it for that local network. End Edit

Before we run any diagnostics, we can see one immediate problem. Note the prompt for ‘Password:’.

First tip: WinXP Home has no support for password based file shares. Password based file shares are optional for WinXP Professional. In the Windows world, all simple file shares assume there are no username/password pairs. Therefore, the above command was incorrect.

When trying to attach any simple Windows based file shares, you need to add ‘-o guest’ to the mount command. Simple in this case means no password restricted file shares which means no user authentication of any kind. Repeat: All WinXP Home based file share are simple . Most home users of WinXP Professional will also be using simple file shares as will Win 7 users whose file shares are set in WinXP compatibility mode.

The above command should look more like this:

This command also failed but we were no longer prompted for ‘Password’. Yeah! First problem resolved.

To head off a possible point of confusion, please note that mount -t cifs and mount.cifs are the exactly equivalent. All these examples are cut and pasted from real life.

The first diagnostic we need to run is smbtree . This will confirm everything that’s actually visible on the network from Samba’s point of view. The results should prove:

• You have Samba correctly installed.
• What file shares/printers are available for you to attach.

Do not run this diagnostic tool on a network with a lot of PCs. The options you should use are:

These options will run smbtree without the need or confusion to determine who the ‘master browser’ is and restrict the output to simple shares (no password) only.

The following is a typical example from my home network:

If you’re on a network with more than a handful of computers, this listing can be quite long. Instead of running smbtree , you can run nmblookup . To run this command, you need an additional bit of information. That information is the IP address of the computer which hosts the file share you want to attach. As you can see from the above mount command, I have this information. There are one option you’ll want to use:

This option reduces all the actions needed to perform the query to the barest minimum possible. This is an important point with implications I’ll address further down.

Here is a typical example of the query:

The results show us two things:

• We have Samba properly installed.
• The file share host is visible on our network.

Now that we’ve verified Samba is working and that the host is visible, we’re ready to take the next diagnostic step. From both the smbtree and nmblookup commands, we know the Windows name of the host computer is SWEET. We therefore try our mount command using SWEET instead of 192.168.1.100:

Second Tip: When one computer can’t find another computer by name, then we always punt. In this case, punting means to explicitly set up an entry in our local client’s /etc/hosts file for the target share server:

We do this so that we rely upon only our local client and the target share host to establish a connection. It’s part of the bog standard diagnostic process to reduce number of possible failed components to the minimum needed.

Now, we try our mount command again:

Success!! We can now access file shares and printer shares on the target host computer.

This is not the ideal solution. Rather the ‘name’ of the target share host and its associated IP address is supposed to be already available on our network. Moreover, this is supposed to happen automatically.

Observations:

In this case SWEET (as can be seen from the nmblookup results) is the wins master browser on my local network. Yet no name/address association was available. I have had problems in the past with the wins master browser service in mixed environments. Crap happens. I should probably force configure the samba daemon on my internal network’s server (SLIZARD) to be wins master browser.

In home networks which use an off the shelf router to connect to the internet, it is my personal observation that local name resolution may not happen. The default configuration of the OTS router is to support DNS service pass through for queries outside of the local lan.

As far as I’ve experienced, all distributions perform minimalist configuration installations. This means that these minimal configuration settings may assume working services that are not actually working such as a working wins or dns service.

Because of things like local caching (share name and IP being retained across reboots over time), it is possible for one client PC to have no problem with making a share connection while another either loses that ability or is never able to attach the share. Don’t make the mistake of saying one PC is broken because another PC is still works.

In fact, said cached information can be lost due to simply performing an upgrade. It’s not that the updated programs are broken. Instead, all the cached values are cleared during the upgrade. If your wins master browser is not working properly, then your wins resolution will never happen.

Depending on which machine on your network is the wins master browser and the version of Windows it’s running, the strategy employed to refresh the wins master browser cache can range from stupid to really, really stupid. It is my understanding that after a wins master browser first initializes it’s cache, it won’t walk the local network again looking for new additions. Rather, it expects new additions to the local network to essentially add themselves.

Name resolution goes through a descending hierarchy of protocols. The last resort bottom name resolution protocol simply checks the /etc/hosts file. In theory however, explicitly specifying an IP address is supposed to always work too. I’m still surprised that my original mount command did not work. On the other hand, the added entry to the /etc/hosts file did work.

The bottom line is that if you see a mount error(115): Operation now in progress message when trying to mount any cifs based network share, you most likely have a name resolution problem. Your equipment, software and physical connections are probably all fine. I re-iterate: Don’t simply assume your equipment is broken or an upgrade was faulty or even that your configuration may be incorrect. Things may actually be working as designed.

In my example, lack of an internally available DNS combined with a stupid wins master browser are the root cause.

This episode has enhanced my motivation to build (re-purpose) a custom router again with a proper DNS as well as forcing it to be th wins master browser.

Threads which may be of interest in terms of the above discussion and hindsight perspective:

Samba Oddities
cifs-utils: Windows share cannot be mounted anymore after dist-upgrade
Mount Error
Error -115 when mounting share (cifs)
Mounting a Windows computer with two IP addresses
_________________
People whom think M$ is mediocre, don’t know the half of it. Вернуться к началу

monkeyman
n00b

Зарегистрирован: 04 сен 2013
Сообщений: 1

Вернуться к началу

jesnow
l33t

Зарегистрирован: 26 апр 2006
Сообщений: 769

Вернуться к началу

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах

Copyright 2001-2023 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy

Источник

Adblock
detector

Well, I thought it was corrected with the path change and was able to mount everything but after a restart I’m seeing the error again.

fstab entries (I’ve tried many variations on these, but these are current)
//192.168.254.25/plex /mnt/plex/storage cifs vers=1.0,user=guest,password= 0 0
//192.168.254.25/plex2 /mnt/plex/storage2 cifs user=guest,password= 0 0

Error seen upon mount attempt
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

dmesg
[ 1010.144200] CIFS VFS: Error connecting to socket. Aborting operation.
[ 1010.144210] CIFS VFS: cifs_mount failed w/return code = -115
[ 1010.146774] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 1020.383355] CIFS VFS: Error connecting to socket. Aborting operation.
[ 1020.383366] CIFS VFS: cifs_mount failed w/return code = -115

I added vers=1.0 to the first entry based off of the dmesg output but I’m still seeing both fail to mount. I’ve read specifying the version should help, but didn’t have any luck with that so far but I’m probably just missing something.

I’ve not tried to use a credentials file, attempting to use these as anonymous shares. Should I need the credentials file?

**update**
$ sudo mount -t cifs -o username=guest,password= //192.168.254.25/plex /mnt/plex/storage
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
$ smbclient -L 192.168.254.25
Connection to 192.168.254.25 failed (Error NT_STATUS_IO_TIMEOUT)

smb.conf
[global]
workgroup = ELYSIUM
security = user
log level = 1
passdb backend = tdbsam

printing = cups
printcap name = cups
load printers = yes
cups options = raw

unix charset = UTF-8
dos charset = CP932
map to guest = Bad User
username map = /etc/samba/smbusers
guest account = nobody

[plex]
path = /mnt/plex-storage
writable = yes
browsable = yes
guest ok = yes
guest only = no
create mode = 0777
directory mode = 0777

[plex2]
path = /mnt/plex-storage2
writable = yes
browsable = yes
guest ok = yes
guest only = yes
create mode = 0777
directory mode = 0777

Страницы: [1] 2  Все   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1] 2  Все   Вверх

What happened:
A pod unable to attach or mount volumes

The error:
Warning FailedMount 15s kubelet, aks-nodepool1-* (combined from similar events): MountVolume.SetUp failed for volume «pvc-» : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: —description=Kubernetes transient mount for /var/lib/kubelet/pods/ —scope — mount -t cifs -o cache=none,dir_mode=0777,file_mode=0777,gid=1000,mfsymlinks,nobrl,uid=1000,username=,password=,vers=3.0 //.file.core.windows.net/kubernetes-dynamic-pvc- /var/lib/kubelet/pods/1*/volumes/kubernetes.io~azure-file/pvc-*
Output: Running scope as unit run-*.scope.
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

How to reproduce it (as minimally and precisely as possible):

StorageClass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1000
  - gid=1000
  - mfsymlinks
  - nobrl
  - cache=none
parameters:
  skuName: Standard_LRS

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk-upload
  namespace: lego
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: azurefile
  resources:
    requests:
      storage: 500Mi

PV:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                              STORAGECLASS   REASON   AGE
pvc-4641a509-ccfa-4e2a-95b6-a43f6cbeed14   1Gi        RWX            Delete           Bound    lego/azure-managed-disk-upload     azurefile               13d

Anything else we need to know?:
Storage and Nodes are in the same region.
The nodes are in a Virtual Network
We haven’t enabled TCP 445 in our firewall, it is not clear from the documentation if is required.
The documentation we followed:
https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic#required-ports-and-addresses-for-aks-clusters
The troubleshoot documentation:
https://docs.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-linux-file-connection-problems

Environment:

• Kubernetes version:
  Client Version: version.Info{Major:»1″, Minor:»16″, GitVersion:»v1.16.0″, GitCommit:»2bd9643cee5b3b3a5ecbd3af49d09018f0773c77″, GitTreeState:»clean», BuildDate:»2019-09-18T14:36:53Z», GoVersion:»go1.12.9″, Compiler:»gc», Platform:»linux/amd64″}
  Server Version: version.Info{Major:»1″, Minor:»16″, GitVersion:»v1.16.7″, GitCommit:»1fc58d90cc4bc569394d9a882522adcb99fbaa57″, GitTreeState:»clean», BuildDate:»2020-04-03T15:20:08Z», GoVersion:»go1.13.6″, Compiler:»gc», Platform:»linux/amd64″}
• Size of cluster: 3
• General description of workloads in the cluster: Python Flask
• Others: Node OS Ubuntu 16.04

Linux Mint Forums

Welcome to the Linux Mint forums!

SOLVED: Samba problems, mount error(115): Operation now in

SOLVED: Samba problems, mount error(115): Operation now in

Post by Pekka » Mon Feb 16, 2015 2:43 pm

I also posted this to Ubuntu forums, but might as well try this too.

My Samba suddenly stopped working.

I have a samba server, called mjolnir, at 192.168.1.22, running ubuntu 14.04, and a client, running Mint 17.1.

Fstab is as follows:

Mounting with smbclient also fails:

I can ping the server:

Re: Samba problems, mount error(115): Operation now in progr

Post by altair4 » Mon Feb 16, 2015 6:40 pm

Never seen that error message personally so let’s see how far we can get here.

[1] DId you look at the output of «testparm -s» on the Mint client?

Most of smb.conf relates to a server but some things like «encrypt passwords» for example also affect the client. Might be worth posting it.

[2] Can I assume that a gvfs mount results in the same problem:

[3] An obvious thing would be mount.cifs itself.

I never remember if Mint installs this package by default or not so you might want to check:

[4] Any firewall changes?

You might want to disable them both just to see if it’s on the way.

Sorry if this seems like a «shotgun approach» but this error just doesn’t come up very often.

EDIT: There’s a storm coming my way and it doesn’t take much where I happen to be at the moment for power to go out for who knows how long. I will get back to this when I can should that occur.

Источник

PROBLEM:

Mount error 115 on some shares? (LINUX)

SOLUTION 1:

• Running debian wheezy on a virtual machine and trying to mount some shares from the win8.1 host.

• The first share gets mounted correctly, but not the other two.
• This is the output we get when sudo-ing a mount -a:

and this is what /var/log/syslog shows:

• The same happens at boot time.

Now, we run manually :

SOLUTION 2:

mount error(115): Operation now in progress … CIFS VFS: cifs_mount failed w/return code = -115

• Trying to mount a CIFS path in Ubuntu and getting:
• mount error(115): Operation now in progress
• Try to look this /var/log/syslog:

• Socket error, we know what this is right? IP or port. Ping for domain/IP or Telnet to test port:

• Telnet was timing out, port closed for IP in firewall.

SOLUTION 3:

LEM mount error(115): Operation now in progress

Overview

• This article describes an error during the LEM upgrade process where you are asked to specify a network share location containing upgrade files.
• After entering the network share as \hostnamesharename and the username and password, LEM throws this error and will fail the upgrade process:

Mount error(115): Operation now in progress

Cause

• A network name resolution failing on the smb client in LEM.

Resolution

• Check ICMP connectivity (ping) between the hosts.
• Attempt to mount a share on the same subnet as LEM.
• Attempt to use the IP address and a simple share name when mounting the share.

e.g. \10.1.1.1lem rather than \some_host_some_place_on_the_networkthis_share.name_desktop_special_unique_and_long

You may also like

Should You Be Using a VPN for Gaming?

The best Open-Source VPNs for Linux and Windows

VPS Server Space OR Disk Quota

Wikitechy Editor

Wikitechy Founder, Author, International Speaker, and Job Consultant. My role as the CEO of Wikitechy, I help businesses build their next generation digital platforms and help with their product innovation and growth strategy. I’m a frequent speaker at tech conferences and events.

Источник

Mount error 115 linux

Edit: Point of clarification — In the examples below, you’ll notice I use a domain name of ‘lamasondufeu’. I always make use of a domain name on mixed networks in order to enforce Windows Workgroup naming consistency. By default, Samba will use the domain name of the computer it’s running on as the ‘Windows Workgroup’ unless you explicitly provide one in smb.conf. Also by default, WinXP always uses ‘workgroup’ as it’s value for ‘Windows Workgroup’.

All computers which expect to talk to each other using Windows networking need to either be in the same Workgroup or you need to explicitly which workgroups they are allowed to talk to. Selecting a specific domain name for your network and using that as your Windows Workgroup name makes mixed networks much easier to adminster. Also, it’s considered bad security practice to leave the Windows Workgroup name at it’s default value so this is something you want to change anyway.

It’s always good policy on multi-computer local networks to pick your own domain name and stick with it for that local network. End Edit

Before we run any diagnostics, we can see one immediate problem. Note the prompt for ‘Password:’.

First tip: WinXP Home has no support for password based file shares. Password based file shares are optional for WinXP Professional. In the Windows world, all simple file shares assume there are no username/password pairs. Therefore, the above command was incorrect.

When trying to attach any simple Windows based file shares, you need to add ‘-o guest’ to the mount command. Simple in this case means no password restricted file shares which means no user authentication of any kind. Repeat: All WinXP Home based file share are simple . Most home users of WinXP Professional will also be using simple file shares as will Win 7 users whose file shares are set in WinXP compatibility mode.

The above command should look more like this:

This command also failed but we were no longer prompted for ‘Password’. Yeah! First problem resolved.

To head off a possible point of confusion, please note that mount -t cifs and mount.cifs are the exactly equivalent. All these examples are cut and pasted from real life.

The first diagnostic we need to run is smbtree . This will confirm everything that’s actually visible on the network from Samba’s point of view. The results should prove:

• You have Samba correctly installed.
• What file shares/printers are available for you to attach.

Do not run this diagnostic tool on a network with a lot of PCs. The options you should use are:

These options will run smbtree without the need or confusion to determine who the ‘master browser’ is and restrict the output to simple shares (no password) only.

The following is a typical example from my home network:

If you’re on a network with more than a handful of computers, this listing can be quite long. Instead of running smbtree , you can run nmblookup . To run this command, you need an additional bit of information. That information is the IP address of the computer which hosts the file share you want to attach. As you can see from the above mount command, I have this information. There are one option you’ll want to use:

This option reduces all the actions needed to perform the query to the barest minimum possible. This is an important point with implications I’ll address further down.

Here is a typical example of the query:

The results show us two things:

• We have Samba properly installed.
• The file share host is visible on our network.

Now that we’ve verified Samba is working and that the host is visible, we’re ready to take the next diagnostic step. From both the smbtree and nmblookup commands, we know the Windows name of the host computer is SWEET. We therefore try our mount command using SWEET instead of 192.168.1.100:

Second Tip: When one computer can’t find another computer by name, then we always punt. In this case, punting means to explicitly set up an entry in our local client’s /etc/hosts file for the target share server:

We do this so that we rely upon only our local client and the target share host to establish a connection. It’s part of the bog standard diagnostic process to reduce number of possible failed components to the minimum needed.

Now, we try our mount command again:

Success!! We can now access file shares and printer shares on the target host computer.

This is not the ideal solution. Rather the ‘name’ of the target share host and its associated IP address is supposed to be already available on our network. Moreover, this is supposed to happen automatically.

Observations:

In this case SWEET (as can be seen from the nmblookup results) is the wins master browser on my local network. Yet no name/address association was available. I have had problems in the past with the wins master browser service in mixed environments. Crap happens. I should probably force configure the samba daemon on my internal network’s server (SLIZARD) to be wins master browser.

In home networks which use an off the shelf router to connect to the internet, it is my personal observation that local name resolution may not happen. The default configuration of the OTS router is to support DNS service pass through for queries outside of the local lan.

As far as I’ve experienced, all distributions perform minimalist configuration installations. This means that these minimal configuration settings may assume working services that are not actually working such as a working wins or dns service.

Because of things like local caching (share name and IP being retained across reboots over time), it is possible for one client PC to have no problem with making a share connection while another either loses that ability or is never able to attach the share. Don’t make the mistake of saying one PC is broken because another PC is still works.

In fact, said cached information can be lost due to simply performing an upgrade. It’s not that the updated programs are broken. Instead, all the cached values are cleared during the upgrade. If your wins master browser is not working properly, then your wins resolution will never happen.

Depending on which machine on your network is the wins master browser and the version of Windows it’s running, the strategy employed to refresh the wins master browser cache can range from stupid to really, really stupid. It is my understanding that after a wins master browser first initializes it’s cache, it won’t walk the local network again looking for new additions. Rather, it expects new additions to the local network to essentially add themselves.

Name resolution goes through a descending hierarchy of protocols. The last resort bottom name resolution protocol simply checks the /etc/hosts file. In theory however, explicitly specifying an IP address is supposed to always work too. I’m still surprised that my original mount command did not work. On the other hand, the added entry to the /etc/hosts file did work.

The bottom line is that if you see a mount error(115): Operation now in progress message when trying to mount any cifs based network share, you most likely have a name resolution problem. Your equipment, software and physical connections are probably all fine. I re-iterate: Don’t simply assume your equipment is broken or an upgrade was faulty or even that your configuration may be incorrect. Things may actually be working as designed.

In my example, lack of an internally available DNS combined with a stupid wins master browser are the root cause.

This episode has enhanced my motivation to build (re-purpose) a custom router again with a proper DNS as well as forcing it to be th wins master browser.

Threads which may be of interest in terms of the above discussion and hindsight perspective:

Samba Oddities
cifs-utils: Windows share cannot be mounted anymore after dist-upgrade
Mount Error
Error -115 when mounting share (cifs)
Mounting a Windows computer with two IP addresses
_________________
People whom think M$ is mediocre, don’t know the half of it. Вернуться к началу

monkeyman
n00b

Зарегистрирован: 04 сен 2013
Сообщений: 1

Вернуться к началу

jesnow
l33t

Зарегистрирован: 26 апр 2006
Сообщений: 755

Вернуться к началу

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах

Copyright 2001-2022 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy

Источник

Adblock
detector