Solved Mounting Samba/CIFS shares at boot time

B

balanga

I have found many threads on these forums dealing with Samba shares, but many are from years ago, and things may well have changed. What I wanted to do was mount Samba/CIFS shares at boot time without having to enter a password. I saw some messages saying you needed a password in /etc/nsmb.conf. I've just noticed that '-N' is available to suppress password. The man pages mount_smbfs(8) mention this. They also mention how to mount Samba shares at boot time via fstab

It is also possible to use fstab(5) for smbfs mounts (the example below
doesn't prompt for a password):

//guest@samba/public /smb/public smbfs rw,noauto,-N 0 0
Click to expand...

Unfortunately that doesn't work for me.
 
That would be quite insecure if you could just access a password protected share by just supressing to prompt for it on with '-N' from the client ;)

I haven't used samba for a long time but as far as I remember '-N' just supresses to prompt for the password and then attempts to read it password from
~/.nsmbrc and then from /etc/nsmb.conf

An example file is in /usr/share/examples/smbfs/examples/dot.nsmbrc
That's also mentioned in mount_smbfs(8) but the manpage is confusing.

Say it would be my server with IP 192.168.1.3 and my username is 'guest' then the entry in /etc/nsmb.conf would look like this:
Code: 
[192.168.1.3:GUEST]
password=$$16146209823

The password as you see is not plain text, but has a simple encryption to it.
You can and you should encrypt your password with the command: (I hope this still applies)
smbutil crypt YOURPASSWORD
The output has to be prefixed with $$1 (or is it allready? I can't remember) and than entered in password=$$1......

That's it. Only to mention that using the IP with '-I192.168.1.3' (capital i with IP appended) adress was more reliable for me like that:
Code: 
//guest@192.168.1.3/public /smb/public smbfs rw,noauto,-N,-I192.168.1.10 0 0
 
Security is not really a concern to me as I am only using a home network.

I tried your suggestion with the '-I' parameter but the mount didn't occur on boot, but I will keep trying...Maybe I'll stumble across the correct syntax.
 
balanga said:
I tried your suggestion with the '-I' parameter but the mount didn't occur on boot, ....
Click to expand...

If you used the options you posted in your quote in the OP or tried k.jacker's command without modification, you're telling the system to not mount on system startup.

fstab manpage:
Code: 
If the option ``noauto'' is specified, the file system will not be auto-
     matically mounted at system startup.  Note that, for network file systems
     of third party types (i.e., types supported by additional software not
     included in the base system) to be automatically mounted at system
     startup, the extra_netfs_types rc.conf(5) variable must be used to extend
     the rc(8) startup script's list of network file system types.
This might also be useful:
Code: 
If the option ``late'' is specified, the file system will be automati-
     cally mounted at a stage of system startup after remote mount points are
     mounted.  For more detail about this option, see the mount(8) manual
     page.
 
This may not be exactly what you are looking for, but it may provide helpful hints in the direction you are moving. I didn't want to mount my shares at boot time, but rather have my user mount the shares on login.

In order to allow a normal user to mount a samba share I had to do the following, which, to my knowledge is not secure: chmod 4555 /usr/sbin/mount_smbfs

I also had to create a .nsmbrc file in my home directory:
Code: 
[<IP_OF_SERVER>]
addr=<IP_OF_SERVER>
[<IP_OF_SERVER>:<USERNAME>]
password=<PASSWORD>
example:
Code: 
[192.168.1.100]
addr=192.168.1.100
[192.168.1.100:myusername]
password=mypassword

If you haven't already done so, on your server, you need to create the user (via both adduser and pdbedit):
pdbedit -a [username]


Making your uid the same on both server and client may help mitigate potential issues.

Finally, when my user logs in, a shell script fires to see if the mounts are already available, and if not, then mount them.
 
linux->bsd said:
If you used the options you posted in your quote in the OP or tried k.jacker's command without modification, you're telling the system to not mount on system startup.

fstab manpage:
Code: 
If the option ``noauto'' is specified, the file system will not be auto-
     matically mounted at system startup.  Note that, for network file systems
     of third party types (i.e., types supported by additional software not
     included in the base system) to be automatically mounted at system
     startup, the extra_netfs_types rc.conf(5) variable must be used to extend
     the rc(8) startup script's list of network file system types.
Click to expand...

Thanks for pointing out the 'noauto' option. I removed it and now have the Samba share mounted on bootup, just as I wanted. It's often difficult to know what all the options on a command line do. I tend to blindly copy what anyone suggests and hope for the best :).
 
k.jacker said:
Say it would be my server with IP 192.168.1.3 and my username is 'guest' then the entry in /etc/nsmb.conf would look like this:
Code: 
[192.168.1.3:GUEST]
password=$$16146209823

The password as you see is not plain text, but has a simple encryption to it.
You can and you should encrypt your password with the command: (I hope this still applies)
smbutil crypt YOURPASSWORD
The output has to be prefixed with $$1 (or is it allready? I can't remember) and than entered in password=$$1......
Click to expand...

I've just been trying to set this up with a current 11.0-RELEASE system, and found your post discussing it.

You're correct that smbutil crypt YOURPASSWORD creates a hashed password, prefixed with $$1 automatically. However... when I use the hashed password in /etc/nsmb.conf it fails to authenticate. Replacing with a plaintext non-hashed password makes it work.

This makes me wonder if the documentation is up to date, or the hashing algorithm used here isn't supported by every Samba/Windows version. I'm happy it works, but a little confused about how supported the encrypted passwords are.


Regards,
Roger
 
You must log in or register to reply here.
Back
Top