smbmount
smbumount It's cool that you can use smbclient to access Samba shares, but it's also a pain if you want to use a GUI, or if you want to do a lot of work on the share. In those cases, you should use smbmount, which mounts the Samba share to your local filesystem as though it was part of your hard drive. After it's mounted, you can open your favorite file manager and access files on the share easily, and you can even open programs such as word processors and open the files directly with a minimum of fuss. To mount a Samba share on your filesystem, you must create a mount point onto which Linux will graft the share. For instance, if you were going to mount the documents share from ELIOT, you might create a directory like this: $ mkdir /home/scott/eliot_documents
Now you run the smbmount command, along with a whole host of options. [View full width] $ smbmount //eliot/documents /home/scott/eliot_documents -o credentials=/home/scott/bin  /credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING smbmnt must be installed suid root for direct user mounts (1000,1000) smbmnt failed: 1
Before looking at the option, let's talk about why smbmount failed. The second line tells you why: smbmnt, which smbmount calls, can only be run by root. This can be a problem if you want your non-root users to be able to mount Samba shares. The way around that is to set smbmnt as suid root (you learned about suid in Chapter 7's "Set and Then Clear suid"). Note Yes, you're giving ordinary users the ability to use smbmnt as though they were root, but it's not really a big problem. It's certainly better than giving them the root password, or requiring your participation every time they want to mount a Samba share.
Here's how to set smbmnt as suid root. Note In order to save space, some of the details you'd normally see with ls -l have been removed.
# ls /usr/bin/smbmnt -rwxr-xr-x 1 root root /usr/bin/smbmnt # chmod u+s /usr/bin/smbmnt # ls -l /usr/bin/smbmnt -rwsr-xr-x 1 root root /usr/bin/smbmnt
Now let's try smbmount again. [View full width] $ smbmount //eliot/documents /home/scott/eliot_documents -o redentials=/home/scott /credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING $ ls -F /home/scott/eliot_documents presentations/ to_print/
Let's walk through the command you used. After smbmount, //eliot/documents specifies the Samba server and Samba share to which you're connecting. Then comes the path to your mount point, /home/scott/eliot_documents. The -o option indicates that options are coming next. Instead of credentials=/home/scott/credentials_eliot, you could have used any of the following: The first and second choices are completely unsafe because the password would now show up in .bash_history and ps. Don't do that! The final choice prompts you for a password, which would be safe because the password wouldn't appear in either .bash_history or ps. But you're trying to automate the process of mounting the Samba share, so the last choice wouldn't work, either. That leaves you with credentials=/home/scott/credentials_eliot. This tells smbmount that the username and password are stored in a file, in this format: username = scott password = 123456
This is just like the credentials file discussed previously in "Access Samba Resources with an FTP-Like Client," and as in that example, use chmod after you create a credentials file to tightly limit who can view that file. If you don't care about automating the logon process, by all means, use username=scott and get prompted to enter the password, which is certainly the safest option. The fmask and dmask options respectively control the default permissions for any new files and directories that you create in the mounted Samba share. 644 would produce rw-r--r-- for files, while 755 would end up with rwxr-xr-x for directories. Note Don't recall what we're talking about? Take a look back at "Understand the Basics of Permissions" in Chapter 7.
Remember that all usernames and group names are really references to numbers, which you can see in /etc/passwd and /etc/group, respectively. Your user ID number on your current machine might be 1000, but on the Samba server, 1000 could be a completely different user, with the same problem for your group ID. With uid=1001 and gid=1001, you tell the Samba server who you are on the Samba server. In other words, you need to look those numbers up in /etc/passwd and /etc/group on the Samba server, not on your local machine. If you don't, you may create files and directories, only to find that you don't really own them and can't use them the way you want. Finally, workgroup=TURING specifies the workgroup, which is obvious enough. After the share is mounted, you can open your file manager and start browsing the contents of eliot_documents, start OpenOffice.org and directly open a file inside eliot_documents/presentations/, or open a PDF in eliot_documents/to_print and send it to the printer. If you place the following lines in your machine's /etc/fstab file, the share is mounted automatically. [View full width] //eliot/documents /home/scott/eliot_documents smbfs credentials=/home/scott /credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING 0 0
Caution Be very careful changing your /etc/fstab file because mistakes can render your system unbootable. Sure, you can fix that problem (see my book Hacking Knoppix for some tips) but it's still a pain that would be better to avoid with caution and prudence. For more on the fstab file, see man fstab on your system.
If you decide that you don't want to access the Samba share at eliot_documents any longer, you can unmount it with smbumount (notice that's umount, not unmount). $ smbumount eliot_documents smbumount must be installed suid root
How frustrating! You need to set smbumount as suid root, too. $ ls -l /usr/bin/smbumount -rwxr-xr-x 1 root root /usr/bin/smbumount $ sudo chmod u+s /usr/bin/smbumount $ ls -l /usr/bin/smbumount -rwsr-xr-x 1 root root /usr/bin/smbumount
Now the user that mounted eliot_documentsand only that usercan unmount eliot_documents. Root can unmount it, too, because root can do whatever it wants. $ smbumount eliot_documents
And that's it. If you want to verify that smbumount worked, try ls eliot_documents, and there shouldn't be anything in there. You're disconnected from that Samba share. | 