LinuxQuestions.org - Cifs "mount error 13 = Permission denied" CIFS SUCKS

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Cifs "mount error 13 = Permission denied" CIFS SUCKS (https://www.linuxquestions.org/questions/linux-networking-3/cifs-mount-error-13-%3D-permission-denied-cifs-sucks-463271/)

I had the same on two servers, the problem was that the account was asking for a password change at next logon. Took that off and everything is ok now.

Since this thread seems to have lots of hints, here's another one: The domain can (should?) be specified in the credentials file:

Code:

$ cat .smb_credentials 

username=Peter Trenholme

password=<redacted>

domain=TRENHOLME

Hi Guys - my first post

This post was brill - mounting made simple.

my next task is to permantly to mount it - struggling with the code to get this to work - by editing fstab.

Any genius' out there can help?

Cheers

Chris

Just In Case This Helps Someon Else

First: sudo apt-get install cifs-utils

Your credential file should look like this, if you use a workgroup rather than a domain:

username=My User Name Here
password=mypasswordhere234!@#$
workgroup=MYWORKGROUPNAME

If you use a domain, change workgroup to domain and put your domain name in.

As other users have noted, DO NOT USE SPACES UNLESS THERE ARE SPACES IN THE USER NAME, ETC. (e.g. user name is "Linda Sue" so username=Linda Sue would be correct but username=LindaSue will not work.)

Then you can execute something like this:

mount.cifs //$server/$share /media/$share -o credentials=$pathandfile

WHERE $server = netbios name or IP address of the server
$share = share nameso that so that
$pathandfile = /path/to/credentialfilename

That works for me where as mount -t cifs did not. I'm running Natty Narwhal so this might to be due to newer versions.

And, if you want it in your /etc/fstab, something like this might work:

Code:

//192.168.0.4/Documents /cifs/Documents cifs noauto,uid=Peter,gid=Peter,credentials=/home/Peter/.smb_credentials,rw 0 0

//192.168.0.4/FEBE      /cifs/FEBE      cifs noauto,uid=Peter,gid=Peter,credentials=/home/Peter/.smb_credentials,rw 0 0

//192.168.0.4/Public    /cifs/Public    cifs noauto,uid=Peter,gid=Peter,credentials=/home/Peter/.smb_credentials,rw 0 0

Note: I use "noauto" so the Linux boot won't halt when the server is down for some reason, and have my /etc/rc.d/rc.local script run the mount commands if the connection is available. Here's the bash function I use for that purpose:

Code:

#############################################################################

#

# Mount all "noauto" cifs devices in /etc/fstab that exist and are not already

# mounted.

#

#############################################################################

mount_cifs() {

  echo

  echo "Mounting any \"noauto\" cifs devices found in /etc/fstab."

  n_mounted=0

  Ping

  if [ $? -ne 0 ]

  then

    echo "  No network connection is available. Mounting of cifs devices aborted."

    return

  fi

  cifs=$(gawk '$0 ~"^[[:space:]]*[#]" {next}; $0 ~ "[[:space:]]cifs[[:space:]].*noauto" {print $2}' /etc/fstab)

  if [ -n "${cifs}" ]

  then

    for name in ${cifs}

    do

      mounted=$(mount | gawk -v name="${name}" '$0 ~ name {print "yes"}')

      if [ -z "${mounted}" ]

      then

        sucmd mount ${name} &>/dev/null

        if [ $? -eq 0 ]

        then

          echo "  ${name} mounted."

          n_mounted=$((++n_mounted))

        else

          echo "  Failed to mount ${name}."

        fi

      else

        echo "  ${name} is already mounted."

      fi

    done

    [ ${n_mounted} -eq 0 ] && echo "  No unmounted \"noauto\" cifs devices were mounted."

  else

    echo "    No cifs \"noauto\" devices were found in /etc/fstab."

  fi

}



#############################################################################

#

# Test for an active network connection by pinging $1 or, if $1 is null, google.com

#

#############################################################################

Ping() {

  local uri

  [ -n "${1}" ] && uri="${1}" || uri="google.com"

  ping -c 1 "${uri}" &>/dev/null

  return $?

}



#############################################################################

#

# Run a command as "root" and return its returned value

#

#############################################################################

sucmd() {

  local error_code, sucmd

  if [ $(id -u) -eq 0 ]

  then

    sucmd=

  else

    sucmd="sudo"

  fi

  ${sucmd} $*

  error_code=$?

  return ${error_code}

}

I had the same problem logging in to my fsg shares, i eventually found the issue. Whilst the username and password where correct (i use an .smbcredentials file) the user group on the fsg did not have access thus the problem existed.
I have an automount in the fstab that change the user permissions from the default to the required user access using uid=usernumber, gid=groupidnumber

The error above is because of a bug in kernel which got in to the kernel version 2.6.18 and above. The same mount command works great for the kernel version 2.6.17 and below.
Working mount command irrespective of the bug is as below.

$mount -t cifs //win-share-hostname/share /mnt/win -o username=user,password=passwd,domain=xxx

As I read on the post trying to match a solution, the man page (man mount.cifs) gave me a clue to a --verbose option before the options switch, I appreciate all others efforts to solve the problem they gave me clues as to were to look. Here is my solution:

issuing command with --verbose option

Code:

$mount -t cifs //<MachineName>/<SharedFolder> /mnt/Shared --verbose -o username=<DomainName>\<username>,password=<password>,domain=<DomainName>,rw

Yielded results, allowing me to see a missing backslash on the user=domain\user option

Code:

$mount.cifs kernel mount options: ip=<IPaddress>,unc=\\<MachineName>\<SharedFolder>,,ver=1,user=<DomainName><username>,domain=<DomainName>,pass=********

the original command was fixed with an escape character to account for the missing backslash

Code:

$mount -t cifs //<MachineName>/<SharedFolder> /mnt/Shared -o username=<DomainName>\\<username>,password=<password>,domain=<DomainName>,rw

In my case, I am mounting using smbfs and a credentials file in fstab, like so:

//192.168.x.x/sharename /home/username/mountpoint cifs credentials=/home/username/.smbcredentials 0 0

where .smbcredentials contains:

username=serveruser
password="servercomplexpassw()rd"

I consistently received permission denied errors. I created a new user on the server with a simpler password (no funny characters, thus no quotes) and it worked fine after that.

username=serveruser2
password=simplepassword

Did you try the fancy password without the quotes? My Windows user name contains a space character, and I needed to put it in the credentials file without the quotes to get it to work.

This is, in fact, a problem with some Samba tools. They helpfully add quotes to various things being sent to Windows systems which read the quoted string verbatim, and then the string fails to be acceptable at the Windows end. (Note: That's an assumption on my part. I have not verified it, except to remove the quotes from around my user name and a few other strings that Samba stores in my wallet.)

An answer! NTLM encrypted password

I was having the same permission denied (13) error when I mounted from the CLI or fstab to my CIFS/SMB session is to a home NAS, annoyingly it worked fine using the GUI in Fedora 20 but never the CLI.

After reading every forum out there someone made a comment about the password hashing/security method (what a guy he is!... sorry I can't find the post to give you kudos personally). A day later after trying everything else I decided that I would do a Wireshark capture of the GUI and the CLI connections to the server to check the version/dialect being used by my NAS and the client (this is shown in the "Negotiation Protocol Response" message from the file server).

The version information was confirmed as version 1 and didn't give any additional success in my instance but I also found that in the same "Negotiate Protocol Response" message is the "Security Mode" field which shows that the server is requiring encrypted password using challenge and response. So this CLI entry sorted it for me...

mount.cifs //192.168.0.1/share/ /files/share -o user=myusernamehere,domain=MYGROUP,rw,soft,nosuid,uid=1000,gid=1000,vers=1.0,sec=ntlm

If the sec=ntlm entry doesn't work for you then the other options can be found under "man mount.cifs".

HTH!

Quote:

Originally Posted by Matrixx (Post 2425898)

I had the same issue if I entered:
mount -t cifs //hostname/share /mnt/temp -o username=someuser,password=somepassword

But if I entered:
mount.cifs //hostname/share /mnt/temp -o username=someuser,password=somepassword

It works... what is up with that?

It does seem to be an issue with cifs and different Windows systems. W2K3 both work fine but the first one has an issue with Windows XP (for me). The systems are in a domain/forest infrastructure.

works for me. Great thanks.

Odds-on answer to this mystery

I was messing around with this configuring some machines today and made a causal link. This is likely your answer.

Manual attempts to mount SMB drives in Windows encountered errors, basically related to using two separate sets of credentials on separate shares on a single volume. E.g. user1/password1 being supplied on a mount of "share1", user2/password2 being supplied on a mount of "share2".

I changed the permissions to allow user1 to have access to "share2", retried the mount of "share2" using the user1/password1 credentials, and voila, it worked. I moved on.

Later, working on a Linux box I'd noticed the mounts had failed. Previously, they had worked fine. Hmmm... I was getting this CIFS error 13 so I googled it and landed here. I read the thread. I deduced that I'd caused an overlap of credentials and tripped a SAMBA error so sure enough, when I regressed the permissions on these two shares so that user1 could NOT access share2, it mounts ok again.

Moral: if your shares have exclusive permissions CIFS will be fine, but if their permissions overlap and you mount multiple shares using different credentials, the mounts will fail.

Intrepid Traveller,
If you have come this far and STILL do not have a working mount, I have two words for you: Time Synchronization.

Make sure both hosts have NTP on them and are in synch with time. Then you shall mount, and you shall have joy. ...As long as you followed all the other suggestions, above. But CIFS does not like it when systems' time is out of whack, as I have discovered today.

I had two machines, both running CentOS 7.2.1511 (a happy coincidence, I must say!), and one would mount while the other would not. Same Windows server, same credentials, same command, same versions of cifs-utils. But the one host was about 2 days' off in time. We ran ntp, the time was corrected, the mount command worked.