Include password when mounting a drive using cifs
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
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?
permissions mount chmod cifs chown
asked May 8 at 13:26
Tak
261413
add a comment |Â
up vote
0
down vote
favorite
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?
permissions mount chmod cifs chown
asked May 8 at 13:26
Tak
261413
1
What is your definition of permanent? Mounting fromfstab? Either way,man mountand google mounting Windows shares. The gist is that you create a separate credentials file and reference it fromfstabline for the share you want to mount.
– ajeh
May 8 at 16:50
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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?
permissions mount chmod cifs chown
asked May 8 at 13:26
Tak
261413
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?
permissions mount chmod cifs chown
asked May 8 at 13:26
Tak
261413
asked May 8 at 13:26
Tak
261413
asked May 8 at 13:26
Tak
261413
asked May 8 at 13:26
Tak
261413
261413
1
What is your definition of permanent? Mounting fromfstab? Either way,man mountand google mounting Windows shares. The gist is that you create a separate credentials file and reference it fromfstabline for the share you want to mount.
– ajeh
May 8 at 16:50
add a comment |Â
1
What is your definition of permanent? Mounting fromfstab? Either way,man mountand google mounting Windows shares. The gist is that you create a separate credentials file and reference it fromfstabline for the share you want to mount.
– ajeh
May 8 at 16:50
1
1
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.– ajeh
May 8 at 16:50
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.– ajeh
May 8 at 16:50
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
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.
answered May 8 at 22:02
John
419211
This works but it's not a very good idea. If others have root access on the machine then they can read the file,suto him, and then mount and access the data on the share or even usesshwith 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.
– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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 hisfstabusingnfs. That may or may not be available to Tak, though.
– Nasir Riley
May 9 at 11:39
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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.
answered May 8 at 22:02
John
419211
This works but it's not a very good idea. If others have root access on the machine then they can read the file,suto him, and then mount and access the data on the share or even usesshwith 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.
– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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 hisfstabusingnfs. That may or may not be available to Tak, though.
– Nasir Riley
May 9 at 11:39
 |Â
show 1 more comment
up vote
0
down vote
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.
answered May 8 at 22:02
John
419211
This works but it's not a very good idea. If others have root access on the machine then they can read the file,suto him, and then mount and access the data on the share or even usesshwith 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.
– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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 hisfstabusingnfs. That may or may not be available to Tak, though.
– Nasir Riley
May 9 at 11:39
 |Â
show 1 more comment
up vote
0
down vote
up vote
0
down vote
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.
answered May 8 at 22:02
John
419211
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.
answered May 8 at 22:02
John
419211
edited May 9 at 18:36
answered May 8 at 22:02
John
419211
answered May 8 at 22:02
John
419211
answered May 8 at 22:02
John
419211
419211
This works but it's not a very good idea. If others have root access on the machine then they can read the file,suto him, and then mount and access the data on the share or even usesshwith 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.
– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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 hisfstabusingnfs. That may or may not be available to Tak, though.
– Nasir Riley
May 9 at 11:39
 |Â
show 1 more comment
This works but it's not a very good idea. If others have root access on the machine then they can read the file,suto him, and then mount and access the data on the share or even usesshwith 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.
– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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 hisfstabusingnfs. That may or may not be available to Tak, though.
– Nasir Riley
May 9 at 11:39
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.– Nasir Riley
May 8 at 23:58
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.– Nasir Riley
May 8 at 23:58
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
May 9 at 1:13
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
May 9 at 1:13
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I understand that and I said so myself. The only thing that I'm going to suggest is editing your answer to include those caveats so that they are properly accounted for and have the user aware of the fact that he's giving it all away by doing such a thing.
– Nasir Riley
May 9 at 2:19
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
I extended the warning about securing that file. It's a trade off between total security and functional automation/convenience.
– John
May 9 at 3:18
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.– Nasir Riley
May 9 at 11:39
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.– Nasir Riley
May 9 at 11:39
 |Â
show 1 more comment
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442544%2finclude-password-when-mounting-a-drive-using-cifs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
What is your definition of permanent? Mounting from
fstab? Either way,man mountand google mounting Windows shares. The gist is that you create a separate credentials file and reference it fromfstabline for the share you want to mount.– ajeh
May 8 at 16:50