Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.)
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.
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:
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
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.
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.)
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...
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.