mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man m

[MkIII_Supra]

Okay, so this is really annoying and I don't know why it stopped working. I have been using several remote Windows drives without issue for some time now. My current system is an OpenSuSE 11.4 KDE set-up that has been running:

# uptime
13:04pm up 148 days 21:04, 4 users, load average: 0.94, 0.99, 1.27

Well about two hours ago I went to transfer some data files as I have been doing for the last 148 days without a hassle and I noticed the files weren't transferring. So I fired up Webmin (it's what I use to make my life easier when dealing with network drives and such) and noticed that the drives indeed were not mounted. And when I tried to mount them using Webmin (which also has worked just fine the last 148 days) I got this error:

mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Nothing has changed on the machine, it hasn't been rebooted in 148 days and all other network connectivity is fine. But the two Windows machines I have been connecting to... I no longer can. They are in fact up and running:

# ping XXX.XXX.XXX.6
PING XXX.XXX.XXX.6 (XXX.XXX.XXX.6) 56(84) bytes of data.
64 bytes from XXX.XXX.XXX.6: icmp_req=1 ttl=128 time=0.331 ms
64 bytes from XXX.XXX.XXX.6: icmp_req=2 ttl=128 time=0.360 ms
64 bytes from XXX.XXX.XXX.6: icmp_req=3 ttl=128 time=0.375 ms
64 bytes from XXX.XXX.XXX.6: icmp_req=4 ttl=128 time=0.387 ms
64 bytes from XXX.XXX.XXX.6: icmp_req=5 ttl=128 time=0.405 ms
^C
--- XXX.XXX.XXX.6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.331/0.371/0.405/0.032 ms
# ping XXX.XXX.XXX.75
PING XXX.XXX.XXX.75 (XXX.XXX.XXX.75) 56(84) bytes of data.
64 bytes from XXX.XXX.XXX.75: icmp_req=1 ttl=128 time=1.31 ms
64 bytes from XXX.XXX.XXX.75: icmp_req=2 ttl=128 time=0.245 ms
64 bytes from XXX.XXX.XXX.75: icmp_req=3 ttl=128 time=0.244 ms
64 bytes from XXX.XXX.XXX.75: icmp_req=4 ttl=128 time=0.260 ms


Now the next test I did is I fired up KRDC and had no problem logging into the machines remotely. So how do I find what the problem is and how do I fix it so it's not a problem anymore. I am really perplexed as to why it would just stop working. Especially since it was working just fine up until 1100.:confused::confused:

[Pafnoutios]

Have you tried rebooting the Windows machines?

Is this in a Domain or Workgroup setting?

[MkIII_Supra]

I only have physical access to one Windows machine, the other is controlled by ITS. As for Domain or Workgroup... not sure I suppose it's Domain. This is a Windows Active Directory Domain I am working in. All the machines are registered in the domain. I think the issue is on the Linux side but don't know why.

[Pafnoutios]

Was Samba updated recently? Is your linux box a domain member?

[MkIII_Supra]

Was Samba updated recently? Is your linux box a domain member?

Regular security updates and those happened Wednesday of last week. Yes the box is a member, has been for 3 years. Other than regular security updates nothing has changed on my side. The Windows side hasn't been messed with either.

[Pafnoutios]

Are DNS and WINS, winbind (are those the same?) each behaving appropriately? Including reverse lookups?

I think those are important for cooperation in a domain.

[MkIII_Supra]

Hmmm, apparently there was something with the Linux box. I rebooted and everything works now. ??? :confused::confused::confused:

[Bryon Speede]

Is it possible your time was off on the linux server because NTP died? I've seen that happen on virtual hosts when they migrate between blades.

[MkIII_Supra]

The Linux box isn't a server but my primary desktop at work and I am not using NTP. Essentially I use OpenSuSE as my desktop for work and have the remote Windows boxes mapped in using Webmin/CIFS so I can access them via Konqueror and other applications.

[cybertron]

I've run into this before too. I'm not sure about your situation, but I think for me it mostly happens after password changes. Credentials get cached or something and then when you try to mount it again it fails because it's still using your old password. Or something like that. I'm pretty careful about unmounting stuff now before doing password changes so I haven't seen it in a while.

Actually, googling this a bit it looks like there are a number of possible causes of this error, so who knows what it was. Although the fact that it went away after a reboot eliminates quite a few of them.