I'm having a strange mount problem. First some background. The computers involved are in a university laboratory and there are four Windows machines (both XP and Win7) and two Linux machines. For discussion purposes I will refer to three of the the computers. A and B are the Linux boxes, both running Slackware 14.2 and regularly updated, and C is one of the Windows machines. The Windows computers are on an internal network that is not visible from the outside and the Linux machines are connected to both the internal network and the campus network. Each Linux box's purpose is to back up data from the Windows computers.

Machine A has been up and running for about ten years with very little in the way of problems. It is setup so that at regular intervals it will mount a Windows machine in a local directory and then rsync that folder with the local storage folder. It then umounts and moves on to the next Windows machine. Very reliable. Users can then access their data anywhere on campus via Samba shares. No password is required but the shares are read only.

Machine B, a new Linux computer, is set up pretty much the same as B as far as I can see. The only difference is that this computer is intended for use as a backup machine for proprietary data which needs to not be freely available. It's running Samba too but here users need to supply a password to get in and access is restricted to a particular subnet on campus. Otherwise, it's not much different from machine A. Here again, the intention is to mount a Windows share in a local folder and then rsync. This is where the problem occurs.

The mount command I'm using is:

mount -t cifs -o username=fbr1\\xxxxxxxxxxx,password=xxxxxx //192.168.1.100/data /fbr1

(I know from reading posts online about this that I probably should be using -o credentials= but for now I'll keep it the way that it is working and change later)

The mount command above works fine on A but not B. On B I get:

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

No firewall is running on the Windows computer and iptables is not being used on either A or B.

I can smb into C using Dolphin from either A or B. smbclient //192.168.1.100/data -U xxxxxxxxxxx works on both A and B.

Why the observed difference in mounting between A and B?

Are they both fresh installs of Slackware 14.2?

Machine A has had 14.2 on it for some time and B had it installed a few days ago. Both have been updated via slackpkg.

Not running Slackware right now, but this addressed the issue for me:
Adding the 'sec=ntlm' part is what got it for me. Your mileage may vary. From what I remember (it's been a bit since I did this), it's a Windows-related issue (surprise).

Thanks TBone. Already tried that one. No luck.

Cheers.

Have you tried supplying the domain name separately:

Thanks Bob. Just tried using domain=fbr1. No luck. I'm still getting the same error.

New B computer with new ethernet cards and cables. Same problem. A can mount Windows shares. B can't. Both A and B are as much the same as I can make them down to exactly the same config files for samba, sshd etd.

Colour me confused.

thirteen_engines --

Fooling with Windows File Shares these days can be maddening, can't it ...

I've had similar, inexplicable issues mounting Windows Shares on two 'identical' machines on the same LAN -- one works the other does not ...

Other times, perfectly working systems simply stop the day after Patch Tuesday ( or the day after the Windows Admins apply Windows Updates )

Maybe try adding the --verbose flag to the mount.cifs command line. Sometime you'll get extra logging, sometimes not ( ??? why not ??? )

Recently ( since Wanna Cry ), there has apparently been some tightening up of allowed SMB Protocols in recent Windows Updates.

Maybe check out the mount.cifs -o 'vers=xxx' values ?

This fixed mount.cifs recently on a system that suddenly stopped working one Wednesday Morning ( after Patch Tuesday ).

Another time, the fix was to fool around with the sec= Options in the `mount -t cifs -o'...' string.

Try man mount.cifs and search for --verbose and then vers= and sec= for a list of candidate values ...

Be careful to invoke --verbose BEFORE your -o options ...

There were sometimes clues in /var/log/syslog or /var/log/messages when I invoked mount.cifs --verbose //Box/Share /MountPoint -o ...

But then again, sometimes not ... I think it depends on the Windows Box.

One more thing that may-or-may not help is to delete any cached credentials for the Linux Boxen on the Windows-Side ...

HTH and good luck !

-- kjh

1 members found this post helpful.

Thanks kjhambrick. I had already tried most of your suggestions without any luck. I did attempt to use the "ver=" option as you suggested but again, no luck. Still complains about permissions. The thing that I really don't get is that in many, many years of using Linux and Windows computers side-by-side I've never seen this happen before.

Edit: BTW, the Windows machines are all on a local network and are not connected to the internet and so are not regularly updated.

Got it! It turns out that for computer B it is necessary to use "mount -t cifs -o domain=fbr1,username=xxxxxxxxx,password=xxxxxxx //192.168.1.100/data /fbr1"

instead of:

"mount -t cifs -o username=fbr1\xxxxxxxxx,password=xxxxxxx //192.168.1.100/data /fbr1"

Still don't know why the difference between computers A and B but at least it's working.

Thanks everyone for you responses.

1 members found this post helpful.

Can't compute. I gave you the solution, you said it did not work. And not it did?

1 members found this post helpful.