Include password when mounting a drive using cifs

Question

At first I using this to mount a shared drive:

sudo mount -t cifs -o username=myuser //xxx.xxx.xx.xx/myfolder /mnt/windowsshare/

but then I didn't have modify access or ownership to the shared drive so this was solved using this question by mounting the shared drive using:

sudo mount.cifs -o username=myuser,uid=youruser,gid=yourgroup //xxx.xxx.xx.xx/myfolder /mnt/windowsshare/:

it then asks for the password of the network share and then it works.

But when I tried doing this:

sudo mount.cifs -o username=myuser,password=mypassword,uid=youruser,gid=yourgroup //xxx.xxx.xx.xx/myfolder /mnt/windowsshare/

by including the password in the command, it says permission denied, not sure why? Also how I can make this permanent so that I don't have to rewrite the command every time I lose connection or restart the computer?

Solution

BEWARE: all options that automate mounting of remote file systems possess some level of risk. See note at the end of this answer.

To make it permanent and automatically connect/reconnect as needed, use the kernel automounter. This will handle connection dropouts, access timeouts, etc.

Install autofs and configure as follows:

/etc/auto.master

/mounts/  /etc/auto.mymounts --ghost

The --ghost option keeps the mountpoint folder visable on the file system, which makes things smoother for some programs.

The autofs config string would be something like:

/etc/auto.mymounts

/mnt/windowsshare/ -fstype=cifs,rw,credentials=/etc/credentials.autofs ://xxx.xxx.xx.xx/myfolder

This may need extended for some enviornments. NOTE: The vers=2\.1 option will need to be specified if SMB 1 has been turned off on the remote server.

/etc/credentials.autofs

dom=TARGETDOMAIN
user=TARGETUSER
password=TARGETPASSWORD

WARNING! Make that file readable only by root, because the target password is stored in plain text. There are security implications with storing this password in plain text, particularly if you cannot trust root users. These implications must be carefully weighed to assure that there are mitigating controls that adequately address the root level user(s) access risk. One possible option would be to have a separate user created with limited rights to instantiate this connection, and make sure that adequate, auditable logging is enabled so that activities can be traced.

Comments

[ajeh]

What is your definition of permanent? Mounting from fstab? Either way, man mount and google mounting Windows shares. The gist is that you create a separate credentials file and reference it from fstab line for the share you want to mount.

[Nasir Riley]

This works but it's not a very good idea. If others have root access on the machine then they can read the file, su to him, and then mount and access the data on the share or even use ssh with his credentials to gain access to other machines where they shouldn't have it. It may not be very convenient that he has to mount it at each startup but it's better than storing credentials in a plain text file.

[John]

The question was about automating/automapping the remote connection in a way that was permanant and avaliable at startup each time. This requires storage of the password, either in a file, fstab, or in bash history. If others have root access, and aren't trusted, all bets are off. Using fstab, automount, or any other scripted, system level automatic drive mapping techniques would be completely out of the question. In that case even storing a script with that data in the user's home directory isn't secure, because root will get to everything, eventually, even the user's bash history.

[John]

I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.

[Nasir Riley]

It works but it's a trade off that no one would ever do where I work. The convenience of not having to enter credentials isn't worth the risk of storing then in a plain text file. Luckily, where I work, we use Isilon which supports multi-protocol so a share which uses SMB for Windows and MacOSX can also be exported as NFS for Linux which removed the need to enter credentials. I had a user who was accessing an SMB share by storing his credentials so I just added it to his fstab using nfs. That may or may not be available to Tak, though.

[John]

From a pure security perspective, plain text passwords are always bad. From an operational/functional perspective, they are one of several less than ideal realities. Operationally, all options that automate mounting of remote file systems possess some level of risk, even NFS. Finding a balance between those options is beyond this discussion or question, and comes down to the level of acceptable risk.