mount <windows share> gives mount error(5) or (13)

English Network/Internet
1

Hi,

on my new laptop I tried to mount a share of a windows computer using samba. As far as I can tell I have configured everything (samba server, firewall, domain) as with my old laptop (suse 11.1) and using Dolphin it works perfectly. I can also connect from my windows computer to my linux share alright using netlogon.

The problem is, I need a command window mount for applying my backup script. And the mount command in the form

mount -t cifs -o username=WindowsDomain/MyWindowsName //WindowsDomain/ShareName /media/smb/ShareName
gives me: mount error: could not resolve address for WindowsDomain: Unknown error

If I use the ip address, so

mount -t cifs -o username=WindowsDomain/MyWindowsName //ip-address/ShareName /media/smb/ShareName
gives me: mount error(5): Input/output error
(but at least I was asked for my username/password now)

On the net I found one hint saying one has to use one more option now -o sec=ntlm. The syntax is somewhat awkward then. After many errors I found it is now:

mount -t cifs //ip-address/ShareName /media/smb/ShareName -o sec=ntlm,username=WindowsDomain/MyName
and something indeed changed. I now get: mount error(13): Permission denied after entering username/password
I’ve tried for days and searched this forum as well as the net but could not succeed. :frowning: On my old openSuse computer the first form of the mount command still works perfectly. Please note, it also works using Dolphin, so the general configuration cannot be too wrong.

Please help, what am I doing wrong?

Thank you for your efforts.

2

mount -t cifs -o username=hurp,domain=derp,sec=ntlmssp //server/share /mountpoint

If it’s an old Samba box or a NAS based HD it might need ntlm instead of ntlmssp which is Windows XP+. If all fails, try sec=none but that is a really bad idea.

3

Now that gives me the original error message:
mount error(5): Input/output error

So for me it leads to the same behaviour as
mount -t cifs -o username=WindowsDomain/MyWindowsName //ip-address/ShareName /media/smb/ShareName

Just to make one aspect entirely clear: the problem is NOT on my old linux box. Everything works fine there. The problem is with my new laptop and the up-to-date openSuse 13.1.

I noticed one more strange behaviour: If I try to get in my local samba shares (i.e. the directories which I’ve shared on my linux laptop in order to access them from windows) in dolphin I cannot get permission although in that case I am the original owner of that share. I can also not access them from windows now (but I’m pretty sure that used to work earlier on).:open_mouth: To sum up: now only one connection works: Access of the windows shares from linux by using dolphin. Everything else fails.

4

A couple of questions; you didn’t copy the smb.conf from your old system to the new one did you?

Have you tried mounting the share to another directory that you’ve created first, such as /tmp/foobar?

Does --verbose as a parameter print anything meaningful?
For example; mount -t cifs --verbose -o username=foo,sec=ntlm //hurp/derp /meow

IO Error 5 usually refers to things like lack of permissions, inability to contact the server or problems with the server/client communication due to security issues.

5

Thank you for the replies!

I did not copy the smb.conf file but I chose all options in YAST exactly as I did on the old laptop (at least as far as I know - obviously something is not identical). I also compared the two smb.conf files and they look alike to me (apart from different directory names, etc).

For the mountpoint I created a directory in /media/smb/ as I am used to. The directory has permissions 777. I try to mount as root.

Using --verbose I get:

Password for <windows_domain>/<windows_name>@//192.168.0.11/share_name: ********
mount.cifs kernel mount options: ip=192.168.0.11,unc=\192.168.0.11\share_name,sec=ntlm,user=<windows_domain>/<windows_name>,domain=<windows_domain>,pass=*******
mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

I don’t know where the double , , before the “domain” arises. I checked in my command but there is only one , between <windows_name> and “domain=”.

One good news is: I can get unto the Linux machine from my windows computer again. The problem was the permissions of the directory which I had shared (formerly 700). Apparently, I now am “nobody” in group “nobody” when I log in from windows via netlogon (although I give my real linux user name and password in order to connect). So I need permissions 777. On my old machine I used to be “root” when I logged in from windows so the problem did not arise.

So now I’m back with only my original problem: I can connect both ways but from linux to windows in dolphin, only.

6

Do you actually use a DOMAIN account from the Dolphin as well or do you just use a username+pass?

I’m very puzzled here, I tried to replicate your issue in various ways in a VM but I just can’t make it happen - neither in a non-domain machine or a domain machine that is actually part of a Windows 2008 Server forest.

One thing worth checking of course, on the server, is /var/log/samba/log.smbd for errors when you try to connect - perhaps there are hints to what is causing the issue.

7

Miuku is on the right track.

When a Network Share is created on a Windows box, if network security is a Workgroupd and not a Domain, the security is maintained on the Server, you would then present credentials that are resolved on the server (same box where the share exists).

But, when Network Security is implemented (eg a Windows Active Directory Domain), then the credentials are not stored locally on the Server, credentials are stored in a Domain Controller. You must authenticate to a Domain Controller to gain access to network resources which include network shares secured with Domain User accounts.

So,
Probably the simplest solution is to just join your openSUSE box to the Windows Domain (recommend using YAST) and then login to your openSUSE box with a Domain User Account(not your local openSUSE account). Then based on the principles of Single Sign-on, you should then be able to access any Domain resources including the network share automatically.

HTH,
TSU

8

Hi,

things are not solved yet but it sounds to me as if the two of you really know what you are talking about: You are right, the windows workgroup/domain indeed is a little complicated and I’m not sure what it actually is for this case:

It is a domain at my workplace with a proper windows domain server there and my windows laptop a mere client then. When I take my windows laptop home it has remembered the passwords for the users who have logged on during server connection at work (and some network directories which it has synchronised). Now it acts as some kind of backup domain server in the way that I can log on with my domain password (but only users who have ever logged on while the laptop was connected to the server can do this, I can not change my password or add users to the domain or such like).

When I connect at home from my new linux laptop to that windows laptop via dolphin or from my old linux laptop to that windows laptop via mount I always use domain_name/user_name in order to log on to the laptop. I cannot use the computer name. So I called it a domain so far but I’m not actually sure it is correct to say so.

So far I have always given a private domain name for my linux machines (let’s call it “myhome”). So I have myhome set in Yast for “Windows Domain Membership” (but not activated “Also Use SMB Information for Linux Authentication”) and I have set myhome in the Yast-Samba-Server configuration in tab “identity”. There I have also chosen the linux box to be a domain controller. I have not entered any “trusted domains” (I cannot do this as I need a domain password for this which I don’t have - my user pwd does not work). This works still fine for my old linux laptop.

I’ve tried to enter the windows domain name in the Yast samba configuration at “identity” but a domain server is required to administer this addition. So I would be forced to set my linux laptop as a primary domain controller for the workplace domain. I don’t really dare to do this as it might affect the security of the workplace domain.

I have worked out one more hint though, using

smbclient -U windows_domain/windows_user -L windows_domain

On my old linux laptop (where everything works fine) this gives me a list of the windows shares after entering my windows password:

Domain=[windows_domain] OS=[Windows 7 Enterprise 7601 Service Pack 1] Server=[Windows 7 Enterprise 6.1]
<here goes a list of the shares including my share>
session request to windows_domain failed (Called name not present)
session request to *SMBSERVER failed (Called name not present)
NetBIOS over TCP disabled – no workgroup available

On my new linux laptop it gave me the same list of shares (so it knows them!) but then:

Connection to windows_domain failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled – no workgroup available

Does this give you any more ideas?

Once again, thanks for your efforts!:slight_smile:

9

Oh, wow.
You really have to do some reading on Workgroups and Domains. They are very different and you cannot network machines together unless you learn these basics.

Without writing a tome here, here are a few points where you are confused…
And you <must> understand why your “MyHome” is not a Domain but is a Workgroup and how it is used and very differently than what you see set up at work.

  • A Domain Controller is a very special and privileged role in Network Security. Even in a corporate network, there are only a few specially identified machines. No ordinary Host on the network can be a Domain Controller which provides authentication and authorization for the network and you laptop almost certainly is not one.
  • When a Domain Host (like your Windows laptop) is disconnected from the Domain network, it does not become a Domain Controller able to provide authentication for the Domain (eg provide Domain authentication and authorization for other machines). The reason why you are able to login with previously used Domain credentials is because credentials are cached on the machine (and almost certainly subject to expiration after awhile).
  • When you login with Domain credentials, you are authorized to use resources which is Domain security which again requires access to the Domain Controllers which are in your corporate network (You didn’t take those DC capabilities home with you on your laptop). So you cannot create and serve network resources using Domain security because any connecting machine won’t be able to contact a DC.
  • Just because your machine may be a member of a Domain does not mean that resources have to be secured with Domain security (which again will not work outside the corporate network). You also always have the option to use Local Machine security instead which is what happens typically in a Workgroup. Resources secured with Local Machine security means that the authentication and authorization happens locally on the machine and does not make a call to a Domain Controller asking whether presented credentials are valid. Note that unlike “single sign-on” in a Domain which automatically and invisibly does the authentication, authorization and validation, when you use Local Machine credentials to secure a resource, the remote client has to present credentials valid only on that Server machine.

As for your NetBIOS over TCP/IP errors, that only applies to “old style” workgroups, ie XP and earlier. AFAIK later Windows Networking supports hostname resolution to augment the NetBIOS over TCP/IP issues. But, it can also mean that you need to comply with and may be violating NBT naming conventions somewhere. Or maybe your Windows box really is XP (A terrible situation especially in a corporate network).

So, this is what you need to do at home. As long as you are logged in to your machine with Admin (or root if on a Linux box) permissions, you can configure how your network resources (ie network shares) are secured. I doubt your Domain User Account has Admin level permissions so you’ll likely have to login with a Local account with sufficient permissions to be able to setup your network shares.

What I describe is not intended to be complete, only accurate so with a little reading maybe using keywords in my text you should be able to search for additional information to understand what you need to do.

HTH,
TSU

10

Hi,

after being absent for some time I’d now like to continue with fixing or understanding this issue. So, thanks for the explanations on domains and workgroups. The thing is, I cannot do much on the corporate windows 7 machine. I have kind of a local admin account but that one automatically has all network connections shut off, so it is of little help here. Instead, I give the permission to share that directory using my usual domain account and password which the machine has cached (as I learned from Tsu).

Also, I don’t see why I would have to change anything on the Windows box because

  • I can mount the windows share perfectly well from my old linux box.
  • I can connect to the windows share perfectly well using Dolphin on the new linux box.
    The only thing which does not work is the “mount” command on the new linux box.

So my question is: what has been changed in the behaviour of the mount command or what could it be that I missed in configuring the new linux box (using Yast)? One hint could be the error message on the new linux box: Error NT_STATUS_RESOURCE_NAME_NOT_FOUND as described in my last post.

Any ideas?

11

What error do you get if you use sec=krb5 ?

I’m just wondering because it’s clearly an issue with security negotiation, or least it seems to be. The error messages mount/cifs gives are… let’s just say, not very descriptive :slight_smile:

12

This one works for me:

mount -t cifs -o ip=192.168.0.115,domain=domain.local,username=backup_user,password=“secure” //SERVER_NAME/Backup_folder /var/spool/backups

mount -t cifs -o ip=<IP address of Windows Share>,domain=<Windows domain name>,username=<user>,password="<password>" <Full path name of share> <mount point>

13

Hi,

thanks for staying with me!

mount -t cifs --verbose  //<ip>/myshare /media/smb/<my_mountpoint> -o username=<windows_domain/windows_user_name,sec=krb5

leads to:
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount -t cifs -o ip=<ip>,domain=<windows_domain>,username=<windows_user_name> //<windows_computer_name>/<my_share> /media/smb/<my_mountpoint>

works! Alleluia! Thank you so much!

It also works with additionally giving sec=ntlm but apparently that is not necessary.

Wow, wonderful!

I’m getting greedy now: Can I also get rid of the ip-address? It is not always the same, so I have to manually do something there. On my old linux box I can use //<domain_name>/<myshare> instead of //<windows_computer_name>/<my_share>, so I don’t need the ip at all. If I try the command according to marcosaldarriaga but without the ip=… I get:

mount error: could not resolve address for <windows_computer_name>: Unknown error

I found one difference in the configuration of my old linux box vs. the new one:
In Yast, Samba-Server, Tab “identity”: field NetBIOS_Hostname
On the old linux box there is the name of my linux computer, i.e. the old linux box’s name
On the new linux box this field is empty. If I fill it with the name of the new linux box then my own samba shares (the one on the linux box) are no longer visible (not even to me when I’m looking for them on the new linux box using dolphin and neither from any other computer in my network). So I cannot do this as on the old box.

However, all this is not soo important as I can finally run my backup synchronisation script.
Thank you very much indeed!