In this tutorial we’ll take a look at how we can install and configure the Samba server on a host operating system to create a shared folder, which the guest Qemu virtual machines can use.
The first thing we have to do is install Samba, which we can do with one of the following commands based on whichever Linux distribution we have:
1
2
3
4
5
| # Gentooemerge samba# Ubuntuapt-get install samba |
Configuration
After installing Samba, we have to configure it to allow sharing folders on the host computer. The configuration file can be found under /etc/samba/smb.conf and is divided into sections enclosed into brackets [ and ]. Any line starting with a semicolon ‘;’ or hash ‘#’ is a comment and doesn’t do anything to guide the operation of Samba server except give us the description about what each option does.
The default configuration smb.conf has the following sections:
- [global]: global settings that are applied to every other section in the configuration file.
- [homes]: an example of a shared folder, which we can see when scanning a network.
- [printers]: an example configuration for sharing printing capabilities over the network.
The smb.conf has the following configuration options:
| Option | Description |
| workgroup | The name of the workgroup. |
| server string | The NT description field indicating the banner of the Samba service and possibly its version: if %v is used. |
| security | Used security mode, where the following modes are available: - user: the user authenticates with a username and password and the server checks whether the correct credentials were submitted. After that the user will be able to access and mount shares on the server. - share: the user sends an authentication request with a password to access a certain share of the server, where the user has to authenticate for each share it wants to access. - server: the user sends username and password to the Samba server, which in turn sends it to another server on the network, which checks for the validity of the credentials. - domain: the user authenticates to the domain controller, which gives it access to the Samba server. - ads: the user authenticates to the active director. |
| hosts allow | Used to restrict access to certain IPs on the internal network. We must specify networks in a special format, where the last portion of the network range is not included. For example: when we would like to specify that we want to allow IPs in a network 192.168.1.0/24 access this SMB server, we have to specify it like this: ’192.168.1.’ and not ’192.168.1.0′. |
| load printers | Specifies whether we want to automatically rather than manually load the printer list. |
| password server | Only applicable to ‘server’ security mode and specifies the password server that will be used to check whether the entered password was correct or not. If we specify the ‘*’ as the value, Samba will try to find the domain controller by itself. |
| interfaces | Specifies the interfaces the Samba will use. |
| wins support | Specifies whether the WINS server is enabled or disabled. |
| wins server | Instructs Samba to act as WINS client and specifies the IP address of WINS server. |
| wins proxy | Instructs Samba to answer name resolution queries on behalf of non WINS capable client. |
| dns proxy | Specifies whether Samba should try to resolve NetBIOS names via DNS lookups. |
| interfaces | Specifies the interfaces on which the Samba will listen for incoming messages. |
| valid users | Specifies the users allowed to access the share, where we can list an arbitrary number of users. Alternatively, we can use @group to specify a group that has access to the share; users can then be added to the group in /etc/group to give them access to share. We should use a group when multiple users have to access the same shared folder, so we can give them filesystem access with a simple “chmod 770 /home/share/” and “chgrp group /home/share”. |
| invalid users | A list of users who should never be allowed to access the share. We can specify the following in the global configuration, so system users cannot have access to shares: invalid users = root bin daemon … |
| admin users | A list of users who will have superuser/root access to the share. |
| write list | A list of users who have read/write access to the share, although the share is marked as read-only with “read only = yes” option. |
| read list | A list of users who have read only access to the share, although the share is marked as writable with “writable = yes” option. |
| comment | A description of the share. |
| path | The actual path on the Samba server, which will be shared over the network by using SMB protocol. |
| browseable | Specifies whether the clients can browse the share or not. |
| guest ok | Specifies whether clients are able to connect to the share with a guest account without providing a password, which works only when usingshare level security. |
| guest account | Is used when we want to enable a guest account, which doesn’t require a password to be able to access the SMB server. We must specify the account on the operating system that Samba will use to access the share on the system, which can be set to: nobody, guest or any other actual user on the system. |
| guest only | Restricts access only to guest accounts, so all clients connecting to the share will be connected as guests. |
| read only | Specifies whether the share is readable or readable+writeable. |
| writable | This configuration variable is basically the same as “read only” and is used for the same purposes. Only one of the “writable” and “guest only” need to be specified. |
| create mask | Specifies the mask of permissions under which new files will be created. |
| force user | When writing a file to the share, the owner of the file becomes the one specified with “force user”. |
| force group | When writing a file to the share, the group of the file becomes the one specified with “force group”. |
Lets take a look at how clients authenticate to Samba shares. At first Samba checks whether the share supports guest accounts and if it doesn’t, the user must enter username and password to authenticate. When we use share security mode, we’re effectively giving a share a password, which can enable every client that knows the password to connect to that share. If the share is guest only, the user is immediately given access to the share with the user rights as specified with the “guest account” configuration directive; there is no password checking being done. In user security mode, where each client must authenticate with its own username and password, which gives him access to the share. The server and domainsecurity modes are effectively the same as user security mode, except that another server is used to prove whether the entered credentials were correct or not.
Note that when a user logs in to a Samba share, it must pass two levels of restriction. First, it must login with an existing username and password according to Samba. Second, it must also have permission to access to the directory according to the filesystem.
Samba also check the operating system users as well as the ones used with smbpasswd: we must keep this in mind when working with users with Samba. The only exception is the guest account, which we’ll use in this tutorial.
Creating a Shared Folder
To create a shared folder, we much configure the “[homes]” configuration section in smb.conf configuration file. The first thing we can do is rename the share to whichever name we want, like “[shared]“. Since we want the same shared folder as with VirtualBox, we need to use the share security mode, which gives us access to guest only share, which we can use without authenticating. To do that we need to use the following configuration option in the “[global]” section of smb.conf.
1
| security = share |
We also need to add the “guest account” configuration option, which specifies the system account under which we’ll have access to the share. In our case this is user nobody and the configuration option is seen below.
1
| guest account = nobody |
Note that the user ‘nobody’ must be present on the system, which we can easily verify by grepping for the word ‘nobody’ when printing the contents of /etc/passwd file.
1
2
| # cat /etc/passwd | grep nobodynobody:x:65534:65534:nobody:/var/empty:/bin/false |
After that we only need to configure the share we would like to use. We need to specify the comment of the share, the path to the directory we would like to share and whether it’s readable and writable. Configuration options like the ones below are in order:
1
2
3
4
5
6
7
8
9
| comment = Shared Folderpath = /home/user/sharedbrowseable = yesguest ok = yesguest only = yeswritable = yesforce user = nobodyforce group = sharedcreate mask = 0770 |
By declaring the share as guest only, we’ve effectively given access to any user connecting to it without entering a password. If we connect to the share now, it would present us with a shared folder without entering for username and password. On the picture below we can see the contents of the shared folder, which contains only the hello.txt text file.
But because we’re accessing the file as user nobody, we don’t have permissions to write to the shared folder, which means we can’t delete the hello.txt file. If we try to delete it nevertheless, the attempt will fail with a message that we don’t have enough permissions to perform this action as seen below.
If we list the contents of the shared folder on the host operating system, we can see that only the user has write access to the file, but we’re performing the action in the name of nobody.
1
2
3
| # ls -l sharedtotal 0-rw-r--r-- 1 user user 0 Dec 3 16:39 hello.txt |
In order to give both users access to the shared folder, we need to create another group named shared with groupadd command and add users ‘user’ and ‘nobody’ to that group. That can be achieved with the commands seen below.
1
2
3
| # groupadd shared# gpasswd -a user shared# gpasswd -a nobody shared |
After that we need to change the group of the files in the shared directory to shared and chmod 770 to give read and write access to both users on the system.
1
2
| # chown -R nobody:shared /home/user/shared# chmod 770 /home/user/shared |
After that you should be able to delete the files in the shared folder.
Configured smb.conf
For completeness, I’ve presented my whole smb.conf configuration file below, where I’ve deleted all the comments and empty lines to make it easier to read.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| |global|workgroup = WORKGROUPserver string = Sambasecurity = shareload printers = noguest account = nobodylog file = /var/log/samba/log.%mmax log size = 50interfaces = br0dns proxy = no|shared| comment = Shared Folder path = /home/user/shared browseable = yes guest ok = yes guest only = yes writable = yes force user = nobody force group = shared create mask = 0770 |
Conclusion
In this article we’ve looked at how we can setup a shared folder and use it in Qemu. Basically it has little to do with Qemu; the only thing we need to worry about is the “interfaces” option in smb.conf. In my case it’s set to br0, which instructs Samba to bind on bridge br0 interface where my virtual machines are located.
Once more thing to note. On newer versions of Samba, the share security mode is deprecated, which is why you should use the following two options instead: “security = user” and “map to guest = Bad User”; other than that you don’t have to change any of the settings in the smb.conf configuration file.
No comments:
Post a Comment