Mount error 115 operation now in progress что делать

Страницы: [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

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

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:

#SAMBA
//192.168.1.22/ptahome    /home/pekka/pta_mjolnir        cifs    credentials=/home/pekka/.smbcredentials,noexec 0 0
//192.168.1.22/mjolnir-rw    /home/pekka/mjolnir        cifs    credentials=/home/pekka/.smbcredentials,_netdev 0 0
//192.168.1.22/htahome    /home/heli/hta_mjolnir        cifs    credentials=/home/heli/.smbcredentials,_netdev 0 0
//192.168.1.22/music    /media/Music        cifs    guest,_netdev 0 0
//192.168.1.22/pics    /media/Pics        cifs    guest,_netdev 0 0

The samba shares are not mounted at boot. When I try to mount them with «sudo mount -a», I get this:

pekka@Gungnirmint ~ $ sudo mount -a
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)
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)
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.c

ifs)

Mounting with smbclient also fails:

pekka@Gungnirmint ~ $ sudo smbclient -L 192.168.1.22 -U pta
Enter pta's password: 
Connection to 192.168.1.22 failed (Error NT_STATUS_IO_TIMEO

UT)

I can ping the server:

pekka@Gungnirmint ~ $ ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data.
64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=0.484 ms
64 bytes from 192.168.1.22: icmp_seq=2 ttl=64 time=0.436 ms
64 bytes from 192.168.1.22: icmp_seq=3 ttl=64 time=0.446 ms
^C
--- 192.168.1.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.436/0.455/0.484/0.027 m

On the server, testparm gives this:

Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[music]"
Processing section "[pics]"
Processing section "[mjolnir]"
Processing section "[ptahome]"
Processing section "[pinjahome]"
Processing section "[htahome]"
Processing section "[mjolnir-rw]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions


[global]
    server string = Oxbacka-samba
    map to guest = Bad User
    obey pam restrictions = Yes
    pam password change = Yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *Entersnews*spassword:* %nn *Retypesnews*spassword:* %nn *passwordsupdatedssuccessfully* .
    username map = /etc/samba/smbusers
    unix password sync = Yes
    syslog = 0
    log file = /var/log/samba/log.%m
    max log size = 1000
    name resolve order = lmhosts, host, wins, bcast
    dns proxy = No
    idmap config * : backend = tdb
    hosts allow = all

[music]
    path = /home/pta/public/Musaa
    guest ok = Yes

[pics]
    path = /home/pta/public/Kuvia
    guest ok = Yes

[mjolnir]
    path = /mjolnir
    guest ok = Yes

[ptahome]
    comment = Pta-home
    path = /home/pta
    valid users = pta
    read only = No

[pinjahome]
    comment = Pinja-home
    path = /home/pinja
    valid users = pinja
    read only = No

[htahome]
    comment = hta-home
    path = /home/hta
    valid users = hta
    read only = No

[mjolnir-rw]
    comment = Mjolnirw
    path = /mjolnir
    valid users = pta
    read only = No

I recently changed my router, this changed the ip addresses, but I think Samba has worked even after the switch.
Not sure what to try next?