Installing the Samba server

In this recipe, we will learn how to install Samba as our network storage server. Samba is a collection of open source applications that implement Server Message Block (SMB) and Common Internet File System (CIFS) protocols on Unix systems. This allows Samba to be accessible across different types of network system. Samba provides various other functionalities, such as a domain controller for the networks of Windows systems. In this recipe, we will focus on using Samba as a storage server.

Getting ready

You will need access to a root account or an account with sudo privileges

If your server is using any firewall system, make sure to open the necessary network ports. Samba runs on TCP 139 and 445 and UDP ports 137 and 138. Check Chapter 2, Networking, for more details on firewall configuration.

How to do it…

Follow these steps to install the Samba server:

Install the Samba server with the following command:

$ sudo apt-get update
$ sudo apt-get install samba -y

After installation is complete, you can check the Samba version with the following command:
```
$ smbd --version
```
Next, we need to configure Samba to enable sharing on the network. First, create a backup of the original configuration file:
```
$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orignl
```

Next, open smb.conf and replace its contents with the following:

[global]
workgroup = WORKGROUP
server string = Samba Server
netbios name = ubuntu
security = user
map to guest = bad user
dns proxy = no
[Public]
path = /var/samba/shares/public
browsable =yes
writable = yes
guest ok = yes
read only = no
create mask = 644

Next, we need to create a shared directory:
```
$ sudo mkdir -p /var/samba/shares/public
```
Change the directory permissions to make it world writable:
```
$ sudo chmod 777 /var/samba/shares/public
```
Restart the Samba service for the changes to take effect:
```
$ sudo service smbd restart
```

Now you can access this Samba share on the Windows client. Open Windows Explorer and in the address bar, type in \\ubuntu or \\your-server-ip. You should see the shared directory, Public, as follows:

How it works…

Samba is quite an old technology, especially in the age of Cloud storage such as Dropbox and Amazon S3. However, when it comes to private networking, Samba offers a hassle-free setup and is always available for free. All you need is a small server with some free storage space. The release of Samba 4 has added Active Directory (AD) support. Now it's possible to set up Windows AD on Linux servers. Support for AD comes with a wide range of other features, including DNS for name resolution, centralized storage, and authentication with LDAP and Kerberos.

As you can see in the preceding example, setting up Samba is quick and easy, and you can easily get started with network storage within minutes. We can install the Samba server with a single command, as Samba packages are available in the Ubuntu default package repository. After installation, we have created a new quick and dirty configuration file which defines a few parameters, such as the server name (netbios name) and a share definition. We have created a publicly-shared directory where everyone can read and write the contents.

Once you are done with installation and initial testing, make sure that you remove public sharing and enable authenticated access to your Samba shares. You don't want the server to fill up with data from unknown people. In the next recipes, we will take a closer look at user management and access control for Samba shares.

There's more…

To secure your Samba installation and limit access to your local network or subnet, you can use the following configuration parameters:

[globals]
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
bind interfaces only = Yes

This configuration limits Samba to listen only on listed interfaces. In this case, its eth0, the Ethernet network, and lo, localhost. Connection requests from all other hosts are denied.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

Getting ready

You will need access to a root account or an account with sudo privileges

If your server is using any firewall system, make sure to open the necessary network ports. Samba runs on TCP 139 and 445 and UDP ports 137 and 138. Check Chapter 2, Networking, for more details on firewall configuration.

How to do it…

Follow these steps to install the Samba server:

Install the Samba server with the following command:

$ sudo apt-get update
$ sudo apt-get install samba -y

After installation is complete, you can check the Samba version with the following command:
```
$ smbd --version
```
Next, we need to configure Samba to enable sharing on the network. First, create a backup of the original configuration file:
```
$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orignl
```

Next, open smb.conf and replace its contents with the following:

[global]
workgroup = WORKGROUP
server string = Samba Server
netbios name = ubuntu
security = user
map to guest = bad user
dns proxy = no
[Public]
path = /var/samba/shares/public
browsable =yes
writable = yes
guest ok = yes
read only = no
create mask = 644

Next, we need to create a shared directory:
```
$ sudo mkdir -p /var/samba/shares/public
```
Change the directory permissions to make it world writable:
```
$ sudo chmod 777 /var/samba/shares/public
```
Restart the Samba service for the changes to take effect:
```
$ sudo service smbd restart
```

Now you can access this Samba share on the Windows client. Open Windows Explorer and in the address bar, type in \\ubuntu or \\your-server-ip. You should see the shared directory, Public, as follows:

How it works…

Samba is quite an old technology, especially in the age of Cloud storage such as Dropbox and Amazon S3. However, when it comes to private networking, Samba offers a hassle-free setup and is always available for free. All you need is a small server with some free storage space. The release of Samba 4 has added Active Directory (AD) support. Now it's possible to set up Windows AD on Linux servers. Support for AD comes with a wide range of other features, including DNS for name resolution, centralized storage, and authentication with LDAP and Kerberos.

As you can see in the preceding example, setting up Samba is quick and easy, and you can easily get started with network storage within minutes. We can install the Samba server with a single command, as Samba packages are available in the Ubuntu default package repository. After installation, we have created a new quick and dirty configuration file which defines a few parameters, such as the server name (netbios name) and a share definition. We have created a publicly-shared directory where everyone can read and write the contents.

Once you are done with installation and initial testing, make sure that you remove public sharing and enable authenticated access to your Samba shares. You don't want the server to fill up with data from unknown people. In the next recipes, we will take a closer look at user management and access control for Samba shares.

There's more…

To secure your Samba installation and limit access to your local network or subnet, you can use the following configuration parameters:

[globals]
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
bind interfaces only = Yes

This configuration limits Samba to listen only on listed interfaces. In this case, its eth0, the Ethernet network, and lo, localhost. Connection requests from all other hosts are denied.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

How to do it…

Follow these steps to install the Samba server:

Install the Samba server with the following command:

$ sudo apt-get update
$ sudo apt-get install samba -y

After installation is complete, you can check the Samba version with the following command:
```
$ smbd --version
```
Next, we need to configure Samba to enable sharing on the network. First, create a backup of the original configuration file:
```
$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orignl
```

Next, open smb.conf and replace its contents with the following:

[global]
workgroup = WORKGROUP
server string = Samba Server
netbios name = ubuntu
security = user
map to guest = bad user
dns proxy = no
[Public]
path = /var/samba/shares/public
browsable =yes
writable = yes
guest ok = yes
read only = no
create mask = 644

Next, we need to create a shared directory:
```
$ sudo mkdir -p /var/samba/shares/public
```
Change the directory permissions to make it world writable:
```
$ sudo chmod 777 /var/samba/shares/public
```
Restart the Samba service for the changes to take effect:
```
$ sudo service smbd restart
```

Now you can access this Samba share on the Windows client. Open Windows Explorer and in the address bar, type in \\ubuntu or \\your-server-ip. You should see the shared directory, Public, as follows:

How it works…

Samba is quite an old technology, especially in the age of Cloud storage such as Dropbox and Amazon S3. However, when it comes to private networking, Samba offers a hassle-free setup and is always available for free. All you need is a small server with some free storage space. The release of Samba 4 has added Active Directory (AD) support. Now it's possible to set up Windows AD on Linux servers. Support for AD comes with a wide range of other features, including DNS for name resolution, centralized storage, and authentication with LDAP and Kerberos.

As you can see in the preceding example, setting up Samba is quick and easy, and you can easily get started with network storage within minutes. We can install the Samba server with a single command, as Samba packages are available in the Ubuntu default package repository. After installation, we have created a new quick and dirty configuration file which defines a few parameters, such as the server name (netbios name) and a share definition. We have created a publicly-shared directory where everyone can read and write the contents.

Once you are done with installation and initial testing, make sure that you remove public sharing and enable authenticated access to your Samba shares. You don't want the server to fill up with data from unknown people. In the next recipes, we will take a closer look at user management and access control for Samba shares.

There's more…

To secure your Samba installation and limit access to your local network or subnet, you can use the following configuration parameters:

[globals]
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
bind interfaces only = Yes

This configuration limits Samba to listen only on listed interfaces. In this case, its eth0, the Ethernet network, and lo, localhost. Connection requests from all other hosts are denied.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

How it works…

Samba is quite an old technology, especially in the age of Cloud storage such as Dropbox and Amazon S3. However, when it comes to private networking, Samba offers a hassle-free setup and is always available for free. All you need is a small server with some free storage space. The release of Samba 4 has added Active Directory (AD) support. Now it's possible to set up Windows AD on Linux servers. Support for AD comes with a wide range of other features, including DNS for name resolution, centralized storage, and authentication with LDAP and Kerberos.

As you can see in the preceding example, setting up Samba is quick and easy, and you can easily get started with network storage within minutes. We can install the Samba server with a single command, as Samba packages are available in the Ubuntu default package repository. After installation, we have created a new quick and dirty configuration file which defines a few parameters, such as the server name (netbios name) and a share definition. We have created a publicly-shared directory where everyone can read and write the contents.

Once you are done with installation and initial testing, make sure that you remove public sharing and enable authenticated access to your Samba shares. You don't want the server to fill up with data from unknown people. In the next recipes, we will take a closer look at user management and access control for Samba shares.

There's more…

To secure your Samba installation and limit access to your local network or subnet, you can use the following configuration parameters:

[globals]
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
bind interfaces only = Yes

This configuration limits Samba to listen only on listed interfaces. In this case, its eth0, the Ethernet network, and lo, localhost. Connection requests from all other hosts are denied.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

There's more…

To secure your Samba installation and limit access to your local network or subnet, you can use the following configuration parameters:

[globals]
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
bind interfaces only = Yes

This configuration limits Samba to listen only on listed interfaces. In this case, its eth0, the Ethernet network, and lo, localhost. Connection requests from all other hosts are denied.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

Tools for personal file sharing

If you need a simple file sharing tool for your personal use and do not want to set up and configure Samba, then you can try using a tool named OwnCloud. It is very similar to Dropbox and is open source. It gives you web access to all your files and documents. Plus, you get desktop and mobile client apps to sync all files to a remote server.

Another good tool is BitTorrent Sync. Again, this is a file synchronization tool, but this time it is peer-to-peer file synchronization. If you really care about the privacy and security of data, then this tool is made for you. All files are synchronized between two or more systems (say, your desktop and laptop) without the use of any centralized server.

See also

Ubuntu server guide for Samba at https://help.ubuntu.com/lts/serverguide/samba-fileserver.html

Adding users to the Samba server

In the previous recipe, we installed the Samba server and created a public share accessible to everyone. In this recipe, we will learn how to add authentication to the Samba server and password protect shared directories.

Getting ready

You will need access to a root account or an account with sudo privileges.

Make sure that the Samba server is installed and running.

How to do it…

Follow these steps to add users to the Samba server:

Create a new user account. You can use any existing account or add a new Samba only account with the following command. Change smbuser to your desired username:
```
$ sudo useradd -d /home/smbuser -s /sbin/nologin smbuser
```
Now, we need to allocate a Samba password to this new user. First, enter your sudo password, followed by the new password for your Samba account, and then verify the password:
```
$ sudo smbpasswd -a smbuser
```
Create a shared directory for this user and change its ownership:
```
$ sudo chown smbuser:smbuser /var/samba/share/smbuser
```

Next, edit the Samba configuration to add the preceding share:

[Private]
path = /var/samba/shares/smbuser
browsable = yes
writable = yes
valid users = smbuser

Save the changes to the configuration file and reload the Samba server:
```
$ sudo service smbd reload
```
Now, check in Windows Explorer. You should see the new shared directory. On trying to open that directory, you will be asked for a Samba username and password:

How it works…

Samba allows various different types of configuration for shared resources. In the previous recipe, we learned how to set up a public share, and in this recipe we have created a private share for a single user. We have created a new user with the nologin permission. This will allow smbuser to access only the Samba shared directory and nothing else. You can also use existing user accounts on the Ubuntu server.

After adding a user, we set a password to be used with the Samba server. Samba maintains a database of passwords separately from Ubuntu passwords. You can enable or disable Samba users with the following commands:

Enable a Samba user:
```
$ sudo smbpasswd -e username
```
Disable a Samba user:
```
$ sudo smbpasswd -d username
```
Remove a Samba user:
```
$ sudo smbpasswd -x username
```

To enable multiple users to access a shared resource, you can specify the list of users under the valid users line, as follows:

valid users = userone, usertwo, userthree

Similarly, you can limit write permissions to a set of users, as follows:

write list = userone, usertwo

Samba also supports the sharing of users, home directories. This will enable users to create shares for all existing Ubuntu users with a single block of configuration. Add the following lines to the Samba configuration to enable the sharing of home directories:

[homes]
browseable = No
valid users = %S

After this configuration, user's home directories will be available at //server-name/user-name. You will be required to provide a username and password to access these shares. Home directories are by default shared as read only. To enable write permissions, add the following line to the preceding block:

writable = yes

Note that on Windows, you will not be able to access multiple home directories from a single Windows system. Windows does not allow multiple user authentications to a single host.

Alternatively, to share a directory with a group of users, you can use group sharing. Use the following line to share a directory with a group of users:

path=/var/samba/shares/group-share
valid users = @groupname

Then, set group ownership on the directory, group-share:

$ sudo chgrp groupname /var/samba/shares/group-share

There are some other directives such as create mask, directory mask, force user, and force group. These directives can be used to determine the permissions and ownership of the newly created files under Samba share.

After any changes to the Samba configuration file, use testparm to check the configuration for any syntax errors:

$ testparm

It should show the Loaded services file OK message, as listed in following screenshot:

There's more…

With the release of version 4, Samba can be set as a domain controller. Check the official documentation for more details at the following link:

https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

You can also configure the Samba server to authenticate against the LDAP server. LDAP installation and configuration is covered in Chapter 14, Centralized Auth Service. For more details on Samba and LDAP integration, check out the Ubuntu server guide at https://help.ubuntu.com/lts/serverguide/samba-ldap.html.

Getting ready

You will need access to a root account or an account with sudo privileges.

Make sure that the Samba server is installed and running.

How to do it…

Follow these steps to add users to the Samba server:

Create a new user account. You can use any existing account or add a new Samba only account with the following command. Change smbuser to your desired username:
```
$ sudo useradd -d /home/smbuser -s /sbin/nologin smbuser
```
Now, we need to allocate a Samba password to this new user. First, enter your sudo password, followed by the new password for your Samba account, and then verify the password:
```
$ sudo smbpasswd -a smbuser
```
Create a shared directory for this user and change its ownership:
```
$ sudo chown smbuser:smbuser /var/samba/share/smbuser
```

Next, edit the Samba configuration to add the preceding share:

[Private]
path = /var/samba/shares/smbuser
browsable = yes
writable = yes
valid users = smbuser

Save the changes to the configuration file and reload the Samba server:
```
$ sudo service smbd reload
```
Now, check in Windows Explorer. You should see the new shared directory. On trying to open that directory, you will be asked for a Samba username and password:

How it works…

Samba allows various different types of configuration for shared resources. In the previous recipe, we learned how to set up a public share, and in this recipe we have created a private share for a single user. We have created a new user with the nologin permission. This will allow smbuser to access only the Samba shared directory and nothing else. You can also use existing user accounts on the Ubuntu server.

After adding a user, we set a password to be used with the Samba server. Samba maintains a database of passwords separately from Ubuntu passwords. You can enable or disable Samba users with the following commands:

Enable a Samba user:
```
$ sudo smbpasswd -e username
```
Disable a Samba user:
```
$ sudo smbpasswd -d username
```
Remove a Samba user:
```
$ sudo smbpasswd -x username
```

To enable multiple users to access a shared resource, you can specify the list of users under the valid users line, as follows:

valid users = userone, usertwo, userthree

Similarly, you can limit write permissions to a set of users, as follows:

write list = userone, usertwo

Samba also supports the sharing of users, home directories. This will enable users to create shares for all existing Ubuntu users with a single block of configuration. Add the following lines to the Samba configuration to enable the sharing of home directories:

[homes]
browseable = No
valid users = %S

After this configuration, user's home directories will be available at //server-name/user-name. You will be required to provide a username and password to access these shares. Home directories are by default shared as read only. To enable write permissions, add the following line to the preceding block:

writable = yes

Note that on Windows, you will not be able to access multiple home directories from a single Windows system. Windows does not allow multiple user authentications to a single host.

Alternatively, to share a directory with a group of users, you can use group sharing. Use the following line to share a directory with a group of users:

path=/var/samba/shares/group-share
valid users = @groupname

Then, set group ownership on the directory, group-share:

$ sudo chgrp groupname /var/samba/shares/group-share

There are some other directives such as create mask, directory mask, force user, and force group. These directives can be used to determine the permissions and ownership of the newly created files under Samba share.

After any changes to the Samba configuration file, use testparm to check the configuration for any syntax errors:

$ testparm

It should show the Loaded services file OK message, as listed in following screenshot:

There's more…

With the release of version 4, Samba can be set as a domain controller. Check the official documentation for more details at the following link:

https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

You can also configure the Samba server to authenticate against the LDAP server. LDAP installation and configuration is covered in Chapter 14, Centralized Auth Service. For more details on Samba and LDAP integration, check out the Ubuntu server guide at https://help.ubuntu.com/lts/serverguide/samba-ldap.html.

How to do it…

Follow these steps to add users to the Samba server:

Create a new user account. You can use any existing account or add a new Samba only account with the following command. Change smbuser to your desired username:
```
$ sudo useradd -d /home/smbuser -s /sbin/nologin smbuser
```
Now, we need to allocate a Samba password to this new user. First, enter your sudo password, followed by the new password for your Samba account, and then verify the password:
```
$ sudo smbpasswd -a smbuser
```
Create a shared directory for this user and change its ownership:
```
$ sudo chown smbuser:smbuser /var/samba/share/smbuser
```

Next, edit the Samba configuration to add the preceding share:

[Private]
path = /var/samba/shares/smbuser
browsable = yes
writable = yes
valid users = smbuser

Save the changes to the configuration file and reload the Samba server:
```
$ sudo service smbd reload
```
Now, check in Windows Explorer. You should see the new shared directory. On trying to open that directory, you will be asked for a Samba username and password:

How it works…

Samba allows various different types of configuration for shared resources. In the previous recipe, we learned how to set up a public share, and in this recipe we have created a private share for a single user. We have created a new user with the nologin permission. This will allow smbuser to access only the Samba shared directory and nothing else. You can also use existing user accounts on the Ubuntu server.

After adding a user, we set a password to be used with the Samba server. Samba maintains a database of passwords separately from Ubuntu passwords. You can enable or disable Samba users with the following commands:

Enable a Samba user:
```
$ sudo smbpasswd -e username
```
Disable a Samba user:
```
$ sudo smbpasswd -d username
```
Remove a Samba user:
```
$ sudo smbpasswd -x username
```

To enable multiple users to access a shared resource, you can specify the list of users under the valid users line, as follows:

valid users = userone, usertwo, userthree

Similarly, you can limit write permissions to a set of users, as follows:

write list = userone, usertwo

Samba also supports the sharing of users, home directories. This will enable users to create shares for all existing Ubuntu users with a single block of configuration. Add the following lines to the Samba configuration to enable the sharing of home directories:

[homes]
browseable = No
valid users = %S

After this configuration, user's home directories will be available at //server-name/user-name. You will be required to provide a username and password to access these shares. Home directories are by default shared as read only. To enable write permissions, add the following line to the preceding block:

writable = yes

Note that on Windows, you will not be able to access multiple home directories from a single Windows system. Windows does not allow multiple user authentications to a single host.

Alternatively, to share a directory with a group of users, you can use group sharing. Use the following line to share a directory with a group of users:

path=/var/samba/shares/group-share
valid users = @groupname

Then, set group ownership on the directory, group-share:

$ sudo chgrp groupname /var/samba/shares/group-share

There are some other directives such as create mask, directory mask, force user, and force group. These directives can be used to determine the permissions and ownership of the newly created files under Samba share.

After any changes to the Samba configuration file, use testparm to check the configuration for any syntax errors:

$ testparm

It should show the Loaded services file OK message, as listed in following screenshot:

There's more…

With the release of version 4, Samba can be set as a domain controller. Check the official documentation for more details at the following link:

https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

You can also configure the Samba server to authenticate against the LDAP server. LDAP installation and configuration is covered in Chapter 14, Centralized Auth Service. For more details on Samba and LDAP integration, check out the Ubuntu server guide at https://help.ubuntu.com/lts/serverguide/samba-ldap.html.

How it works…

Samba allows various different types of configuration for shared resources. In the previous recipe, we learned how to set up a public share, and in this recipe we have created a private share for a single user. We have created a new user with the nologin permission. This will allow smbuser to access only the Samba shared directory and nothing else. You can also use existing user accounts on the Ubuntu server.

After adding a user, we set a password to be used with the Samba server. Samba maintains a database of passwords separately from Ubuntu passwords. You can enable or disable Samba users with the following commands:

Enable a Samba user:
```
$ sudo smbpasswd -e username
```
Disable a Samba user:
```
$ sudo smbpasswd -d username
```
Remove a Samba user:
```
$ sudo smbpasswd -x username
```

To enable multiple users to access a shared resource, you can specify the list of users under the valid users line, as follows:

valid users = userone, usertwo, userthree

Similarly, you can limit write permissions to a set of users, as follows:

write list = userone, usertwo

Samba also supports the sharing of users, home directories. This will enable users to create shares for all existing Ubuntu users with a single block of configuration. Add the following lines to the Samba configuration to enable the sharing of home directories:

[homes]
browseable = No
valid users = %S

After this configuration, user's home directories will be available at //server-name/user-name. You will be required to provide a username and password to access these shares. Home directories are by default shared as read only. To enable write permissions, add the following line to the preceding block:

writable = yes

Note that on Windows, you will not be able to access multiple home directories from a single Windows system. Windows does not allow multiple user authentications to a single host.

Alternatively, to share a directory with a group of users, you can use group sharing. Use the following line to share a directory with a group of users:

path=/var/samba/shares/group-share
valid users = @groupname

Then, set group ownership on the directory, group-share:

$ sudo chgrp groupname /var/samba/shares/group-share

There are some other directives such as create mask, directory mask, force user, and force group. These directives can be used to determine the permissions and ownership of the newly created files under Samba share.

After any changes to the Samba configuration file, use testparm to check the configuration for any syntax errors:

$ testparm

It should show the Loaded services file OK message, as listed in following screenshot:

There's more…

With the release of version 4, Samba can be set as a domain controller. Check the official documentation for more details at the following link:

https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

You can also configure the Samba server to authenticate against the LDAP server. LDAP installation and configuration is covered in Chapter 14, Centralized Auth Service. For more details on Samba and LDAP integration, check out the Ubuntu server guide at https://help.ubuntu.com/lts/serverguide/samba-ldap.html.

There's more…

With the release of version 4, Samba can be set as a domain controller. Check the official documentation for more details at the following link:

https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

You can also configure the Samba server to authenticate against the LDAP server. LDAP installation and configuration is covered in Chapter 14, Centralized Auth Service. For more details on Samba and LDAP integration, check out the Ubuntu server guide at https://help.ubuntu.com/lts/serverguide/samba-ldap.html.

Installing the secure FTP server

In this recipe, we will learn how to install the File Transfer Protocol (FTP) server and configure it to use SSL encryption.

Getting ready

You will need access to a root account or an account with sudo privileges.

How to do it…

Follow these steps to install the secure FTP server:

Install vsftpd with the following command:

$ sudo apt-get update
$ sudo apt-get install vsftpd

After installation, we can configure vsftpd by editing /etc/vsftpd.conf.

First create the SSL certificate for the FTP server:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

Next, configure Vsftpd. Add or edit the following lines in vsftpd.conf:

anonymous_enable=no
local_enable=yes
write_enable=yes
chroot_local_user=yes
Add the SSL certificate created in the previous step:
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=yes
ssl_ciphers=high
force_local_data_ssl=yes
force_local_logins_ssl=yes

Save and exit the configuration file.
Restart the Vsftpd server:
```
$ sudo service vsftpd restart
```
Now you can use any FTP client that supports the SFTP protocol to connect to your FTP server. The following is the configuration screen for SFTP client FileZilla:

How it works…

FTP is an insecure protocol and you should avoid using it, especially in a production environment. Limit use of FTP to downloads only and use more secure methods, such as SCP, to upload and transfer files on servers. If you have to use FTP, make sure that you have disabled anonymous access and enable SFTP to secure your data and login credentials.

In this recipe, we have installed Vsftpd, which is a default FTP package in the Ubuntu repository. Vsftpd stands for very secure FTP daemon, and it is designed to protect against possible FTP vulnerabilities. It supports both FTP and SFTP protocols.

As Vsftpd is available in the Ubuntu package repository, installation is very simple, using only a single command. After Vsftpd installed, we created an SSL certificate to be used with an FTP server. With this configuration, we will be using the SFTP protocol, which is more secure than FTP. You can find more details about SSL certificates in Chapter 3, Working with Web Servers.

Under the Vsftpd configuration, we have modified some settings to disable anonymous logins, allowed local users to use FTP, enabled write access, and used chroot for local users. Next, we have set a path for previously generated SSL certificates and enabled the use of SSL. Additionally, you can force the use of TLS over SSL by adding the following lines to the configuration file:

ssl_tlsv1=yes
ssl_sslv2=no
ssl_sslv3=no

There's more…

This recipe covers FTP as a simple and easy-to-use tool for network storage. FTP is inherently insecure and you must avoid its use in a production environment. Server deployments can easily be automated with simple Git hooks or the sophisticated integration of continuous deployment tools such Chef, Puppet, or Ansible.

Getting ready

You will need access to a root account or an account with sudo privileges.

How to do it…

Follow these steps to install the secure FTP server:

Install vsftpd with the following command:

$ sudo apt-get update
$ sudo apt-get install vsftpd

After installation, we can configure vsftpd by editing /etc/vsftpd.conf.

First create the SSL certificate for the FTP server:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

Next, configure Vsftpd. Add or edit the following lines in vsftpd.conf:

anonymous_enable=no
local_enable=yes
write_enable=yes
chroot_local_user=yes
Add the SSL certificate created in the previous step:
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=yes
ssl_ciphers=high
force_local_data_ssl=yes
force_local_logins_ssl=yes

Save and exit the configuration file.
Restart the Vsftpd server:
```
$ sudo service vsftpd restart
```
Now you can use any FTP client that supports the SFTP protocol to connect to your FTP server. The following is the configuration screen for SFTP client FileZilla:

How it works…

FTP is an insecure protocol and you should avoid using it, especially in a production environment. Limit use of FTP to downloads only and use more secure methods, such as SCP, to upload and transfer files on servers. If you have to use FTP, make sure that you have disabled anonymous access and enable SFTP to secure your data and login credentials.

In this recipe, we have installed Vsftpd, which is a default FTP package in the Ubuntu repository. Vsftpd stands for very secure FTP daemon, and it is designed to protect against possible FTP vulnerabilities. It supports both FTP and SFTP protocols.

As Vsftpd is available in the Ubuntu package repository, installation is very simple, using only a single command. After Vsftpd installed, we created an SSL certificate to be used with an FTP server. With this configuration, we will be using the SFTP protocol, which is more secure than FTP. You can find more details about SSL certificates in Chapter 3, Working with Web Servers.

Under the Vsftpd configuration, we have modified some settings to disable anonymous logins, allowed local users to use FTP, enabled write access, and used chroot for local users. Next, we have set a path for previously generated SSL certificates and enabled the use of SSL. Additionally, you can force the use of TLS over SSL by adding the following lines to the configuration file:

ssl_tlsv1=yes
ssl_sslv2=no
ssl_sslv3=no

There's more…

This recipe covers FTP as a simple and easy-to-use tool for network storage. FTP is inherently insecure and you must avoid its use in a production environment. Server deployments can easily be automated with simple Git hooks or the sophisticated integration of continuous deployment tools such Chef, Puppet, or Ansible.

How to do it…

Follow these steps to install the secure FTP server:

Install vsftpd with the following command:

$ sudo apt-get update
$ sudo apt-get install vsftpd

After installation, we can configure vsftpd by editing /etc/vsftpd.conf.

First create the SSL certificate for the FTP server:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

Next, configure Vsftpd. Add or edit the following lines in vsftpd.conf:

anonymous_enable=no
local_enable=yes
write_enable=yes
chroot_local_user=yes
Add the SSL certificate created in the previous step:
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=yes
ssl_ciphers=high
force_local_data_ssl=yes
force_local_logins_ssl=yes

Save and exit the configuration file.
Restart the Vsftpd server:
```
$ sudo service vsftpd restart
```
Now you can use any FTP client that supports the SFTP protocol to connect to your FTP server. The following is the configuration screen for SFTP client FileZilla:

How it works…

FTP is an insecure protocol and you should avoid using it, especially in a production environment. Limit use of FTP to downloads only and use more secure methods, such as SCP, to upload and transfer files on servers. If you have to use FTP, make sure that you have disabled anonymous access and enable SFTP to secure your data and login credentials.

In this recipe, we have installed Vsftpd, which is a default FTP package in the Ubuntu repository. Vsftpd stands for very secure FTP daemon, and it is designed to protect against possible FTP vulnerabilities. It supports both FTP and SFTP protocols.

As Vsftpd is available in the Ubuntu package repository, installation is very simple, using only a single command. After Vsftpd installed, we created an SSL certificate to be used with an FTP server. With this configuration, we will be using the SFTP protocol, which is more secure than FTP. You can find more details about SSL certificates in Chapter 3, Working with Web Servers.

Under the Vsftpd configuration, we have modified some settings to disable anonymous logins, allowed local users to use FTP, enabled write access, and used chroot for local users. Next, we have set a path for previously generated SSL certificates and enabled the use of SSL. Additionally, you can force the use of TLS over SSL by adding the following lines to the configuration file:

ssl_tlsv1=yes
ssl_sslv2=no
ssl_sslv3=no

There's more…

This recipe covers FTP as a simple and easy-to-use tool for network storage. FTP is inherently insecure and you must avoid its use in a production environment. Server deployments can easily be automated with simple Git hooks or the sophisticated integration of continuous deployment tools such Chef, Puppet, or Ansible.

How it works…

FTP is an insecure protocol and you should avoid using it, especially in a production environment. Limit use of FTP to downloads only and use more secure methods, such as SCP, to upload and transfer files on servers. If you have to use FTP, make sure that you have disabled anonymous access and enable SFTP to secure your data and login credentials.

In this recipe, we have installed Vsftpd, which is a default FTP package in the Ubuntu repository. Vsftpd stands for very secure FTP daemon, and it is designed to protect against possible FTP vulnerabilities. It supports both FTP and SFTP protocols.

As Vsftpd is available in the Ubuntu package repository, installation is very simple, using only a single command. After Vsftpd installed, we created an SSL certificate to be used with an FTP server. With this configuration, we will be using the SFTP protocol, which is more secure than FTP. You can find more details about SSL certificates in Chapter 3, Working with Web Servers.

Under the Vsftpd configuration, we have modified some settings to disable anonymous logins, allowed local users to use FTP, enabled write access, and used chroot for local users. Next, we have set a path for previously generated SSL certificates and enabled the use of SSL. Additionally, you can force the use of TLS over SSL by adding the following lines to the configuration file:

ssl_tlsv1=yes
ssl_sslv2=no
ssl_sslv3=no

There's more…

This recipe covers FTP as a simple and easy-to-use tool for network storage. FTP is inherently insecure and you must avoid its use in a production environment. Server deployments can easily be automated with simple Git hooks or the sophisticated integration of continuous deployment tools such Chef, Puppet, or Ansible.

There's more…

This recipe covers FTP as a simple and easy-to-use tool for network storage. FTP is inherently insecure and you must avoid its use in a production environment. Server deployments can easily be automated with simple Git hooks or the sophisticated integration of continuous deployment tools such Chef, Puppet, or Ansible.

Synchronizing files with Rsync

In this recipe, we will learn how to use the Rsync utility to synchronize files between two directories or between two servers.

How to do it…

Follow these steps to synchronize files with Rsync:

Set up key-based authentication between source and destination servers. We can use password authentication as well, which is described later in this recipe.
Create a sample directory structure on the source server. You can use existing files as well:
```
ubuntu@src$ mkdir sampledir
ubuntu@src$ touch sampledir/file{1..10}
```
Now, use the following command to synchronize the entire directory from the source server to your local system. Note the / after sampledir. This will copy contents of sampledir in the backup. Without /, the entire sampledir will be copied to the backup:
```
ubuntu@dest$ rsync -azP -e ssh ubuntu@10.0.2.8:/home/ubuntu/sampledir/ backup
```
As this is the first time, all files from sampledir on the remote server will be downloaded in a backup directory on your local system. The output of the command should look like the following screenshot:
You can check the downloaded files with the ls command:
```
$ ls -l backup
```
Add one new file on the remote server under sampledir:
```
ubuntu@src$ touch sampledir/file22
```
Now re-execute the rsync command on the destination server. This time, rsync will only download a new file and any other update files. The output should look similar to the following screenshot:
```
ubuntu@dest$ rsync -azP -e ssh ubuntu@10.0.2.8:/home/ubuntu/sampledir backup
```
To synchronize two local directories, you can simply specify the source and destination path with rsync, as follows:
```
$ rsync /var/log/mysql ~/mysql_log_backup
```

How it works…

Rsync is a well known command line file synchronization utility. With Rsync, you can synchronize files between two local directories, as well as files between two servers. This tool is commonly used as a simple backup utility to copy or move files around systems. The advantage of using Rsync is that file synchronization happens incrementally, that is, only new and modified files will be downloaded. This saves bandwidth as well as time. You can quickly schedule a daily backup with a cron and Rsync. Open a cron jobs file with ctontab-e and add the following line to enable daily backups:

$ crontab -e    # open crontab file
@daily rsync -aze ssh ubuntu@10.0.2.50:/home/ubuntu/sampledir /var/backup

In the preceding example, we have used a pull operation, where we are downloading files from the remote server. Rsync can be used to upload files as well. Use the following command to push files to the remote server:

$ rsync -azP -e ssh backup  ubuntu@10.0.2.50:/home/ubuntu/sampledir

Rsync provides tons of command line options. Some options that are used in the preceding example are –a, a combination of various other flags and stands for achieve. This option enables recursive synchronization and preserves modification time, symbolic links, users, and group permissions. Option -z is used to enable compression while transferring files, while option -P enables progress reports and the resumption of interrupted downloads by saving partial files.

We have used one more option, -e, which specifies which remote shell to be used while downloading files. In the preceding command, we are using SSH with public key authentication. If you have not set public key authentication between two servers, you will be asked to enter a password for your account on the remote server. You can skip the -e flag and rsync will use a non-encrypted connection to transfer data and login credentials.

Note that the SSH connection is established on the default SSH port, port 22. If your remote SSH server runs on a port other than 22, then you can use a slightly modified version of the preceding command as follows:

rsync -azP -e "ssh -p port_number" source destination

Anther common option is --exclude, which specifies the pattern for file names to be excluded. If you need to specify multiple exclusion patterns, then you can specify all such patterns in a text file and include that file in command with the options --exclude-from=filename. Similarly, if you need to include some specific files only, you can specify the inclusion pattern with options --include=pattern or --include-from=filename.

Exclude a single file or files matching with a single pattern:

$ rsync -azP --exclude 'dir*' source/ destination/

Exclude a list of patterns or file names:

$ rsync -azP --exclude-from 'exclude-list.txt' source/ destination/

By default, Rsync does not delete destination files, even if they are deleted from the source location. You can override this behavior with a --delete flag. You can create a backup of these files before deleting them. Use the --backup and --backup-dir options to enable backups. To delete files from the source directory, you can use the --remove-source-files flag. Another handy option is --dry-run, which simulates a transfer with the given flags and displays the output, but does not modify any files. You should use --dry-run before using any deletion flags.

Use this to remove source files with --dry-run:

$ rsync --dry-run --remove-source-files -azP source/  destination/

There's more…

Rsync is a great tool to quickly synchronize the files between source and destination, but it does not provide bidirectional synchronization. It means the changes are synchronized from source to destination and not vice versa. If you need bi-directional synchronization, you can use another utility, Unison. You can install Unison on Debian systems with the following command:

$ sudo apt-get -y install unison

Once installed, Unison is very similar to Rsync and can be executed as follows:

$ unison /home/ubuntu/documents ssh://10.0.2.56//home/ubuntu/documents

You can get more information about Unison in the manual pages with the following command:

$ man unison

If you wish to have your own Dropbox-like mirroring tool which continuously monitors for local file changes and quickly replicates them to network storage, then you can use Lsyncd. Lsyncd is a live synchronization or mirroring tool, which monitors the local directory tree for any events (with inotify and fsevents), and then after few seconds spawns a synchronization process to mirror all changes to a remote location. By default, Lsyncd uses Rsync for synchronization.

As always, Lsyncd is available in the Ubuntu package repository and can be installed with a single command, as follows:

$ sudo apt-get install lsyncd

To get more information about Lsyncd, check the manual pages with the following command:

$ man lsyncd

How to do it…

Follow these steps to synchronize files with Rsync:

Set up key-based authentication between source and destination servers. We can use password authentication as well, which is described later in this recipe.
Create a sample directory structure on the source server. You can use existing files as well:
```
ubuntu@src$ mkdir sampledir
ubuntu@src$ touch sampledir/file{1..10}
```
Now, use the following command to synchronize the entire directory from the source server to your local system. Note the / after sampledir. This will copy contents of sampledir in the backup. Without /, the entire sampledir will be copied to the backup:
```
ubuntu@dest$ rsync -azP -e ssh ubuntu@10.0.2.8:/home/ubuntu/sampledir/ backup
```
As this is the first time, all files from sampledir on the remote server will be downloaded in a backup directory on your local system. The output of the command should look like the following screenshot:
You can check the downloaded files with the ls command:
```
$ ls -l backup
```
Add one new file on the remote server under sampledir:
```
ubuntu@src$ touch sampledir/file22
```
Now re-execute the rsync command on the destination server. This time, rsync will only download a new file and any other update files. The output should look similar to the following screenshot:
```
ubuntu@dest$ rsync -azP -e ssh ubuntu@10.0.2.8:/home/ubuntu/sampledir backup
```
To synchronize two local directories, you can simply specify the source and destination path with rsync, as follows:
```
$ rsync /var/log/mysql ~/mysql_log_backup
```

How it works…

Rsync is a well known command line file synchronization utility. With Rsync, you can synchronize files between two local directories, as well as files between two servers. This tool is commonly used as a simple backup utility to copy or move files around systems. The advantage of using Rsync is that file synchronization happens incrementally, that is, only new and modified files will be downloaded. This saves bandwidth as well as time. You can quickly schedule a daily backup with a cron and Rsync. Open a cron jobs file with ctontab-e and add the following line to enable daily backups:

$ crontab -e    # open crontab file
@daily rsync -aze ssh ubuntu@10.0.2.50:/home/ubuntu/sampledir /var/backup

In the preceding example, we have used a pull operation, where we are downloading files from the remote server. Rsync can be used to upload files as well. Use the following command to push files to the remote server:

$ rsync -azP -e ssh backup  ubuntu@10.0.2.50:/home/ubuntu/sampledir

Rsync provides tons of command line options. Some options that are used in the preceding example are –a, a combination of various other flags and stands for achieve. This option enables recursive synchronization and preserves modification time, symbolic links, users, and group permissions. Option -z is used to enable compression while transferring files, while option -P enables progress reports and the resumption of interrupted downloads by saving partial files.

We have used one more option, -e, which specifies which remote shell to be used while downloading files. In the preceding command, we are using SSH with public key authentication. If you have not set public key authentication between two servers, you will be asked to enter a password for your account on the remote server. You can skip the -e flag and rsync will use a non-encrypted connection to transfer data and login credentials.

Note that the SSH connection is established on the default SSH port, port 22. If your remote SSH server runs on a port other than 22, then you can use a slightly modified version of the preceding command as follows:

rsync -azP -e "ssh -p port_number" source destination

Anther common option is --exclude, which specifies the pattern for file names to be excluded. If you need to specify multiple exclusion patterns, then you can specify all such patterns in a text file and include that file in command with the options --exclude-from=filename. Similarly, if you need to include some specific files only, you can specify the inclusion pattern with options --include=pattern or --include-from=filename.

Exclude a single file or files matching with a single pattern:

$ rsync -azP --exclude 'dir*' source/ destination/

Exclude a list of patterns or file names:

$ rsync -azP --exclude-from 'exclude-list.txt' source/ destination/

By default, Rsync does not delete destination files, even if they are deleted from the source location. You can override this behavior with a --delete flag. You can create a backup of these files before deleting them. Use the --backup and --backup-dir options to enable backups. To delete files from the source directory, you can use the --remove-source-files flag. Another handy option is --dry-run, which simulates a transfer with the given flags and displays the output, but does not modify any files. You should use --dry-run before using any deletion flags.

Use this to remove source files with --dry-run:

$ rsync --dry-run --remove-source-files -azP source/  destination/

There's more…

Rsync is a great tool to quickly synchronize the files between source and destination, but it does not provide bidirectional synchronization. It means the changes are synchronized from source to destination and not vice versa. If you need bi-directional synchronization, you can use another utility, Unison. You can install Unison on Debian systems with the following command:

$ sudo apt-get -y install unison

Once installed, Unison is very similar to Rsync and can be executed as follows:

$ unison /home/ubuntu/documents ssh://10.0.2.56//home/ubuntu/documents

You can get more information about Unison in the manual pages with the following command:

$ man unison

If you wish to have your own Dropbox-like mirroring tool which continuously monitors for local file changes and quickly replicates them to network storage, then you can use Lsyncd. Lsyncd is a live synchronization or mirroring tool, which monitors the local directory tree for any events (with inotify and fsevents), and then after few seconds spawns a synchronization process to mirror all changes to a remote location. By default, Lsyncd uses Rsync for synchronization.

As always, Lsyncd is available in the Ubuntu package repository and can be installed with a single command, as follows:

$ sudo apt-get install lsyncd

To get more information about Lsyncd, check the manual pages with the following command:

$ man lsyncd

How it works…

Rsync is a well known command line file synchronization utility. With Rsync, you can synchronize files between two local directories, as well as files between two servers. This tool is commonly used as a simple backup utility to copy or move files around systems. The advantage of using Rsync is that file synchronization happens incrementally, that is, only new and modified files will be downloaded. This saves bandwidth as well as time. You can quickly schedule a daily backup with a cron and Rsync. Open a cron jobs file with ctontab-e and add the following line to enable daily backups:

$ crontab -e    # open crontab file
@daily rsync -aze ssh ubuntu@10.0.2.50:/home/ubuntu/sampledir /var/backup

In the preceding example, we have used a pull operation, where we are downloading files from the remote server. Rsync can be used to upload files as well. Use the following command to push files to the remote server:

$ rsync -azP -e ssh backup  ubuntu@10.0.2.50:/home/ubuntu/sampledir

Rsync provides tons of command line options. Some options that are used in the preceding example are –a, a combination of various other flags and stands for achieve. This option enables recursive synchronization and preserves modification time, symbolic links, users, and group permissions. Option -z is used to enable compression while transferring files, while option -P enables progress reports and the resumption of interrupted downloads by saving partial files.

We have used one more option, -e, which specifies which remote shell to be used while downloading files. In the preceding command, we are using SSH with public key authentication. If you have not set public key authentication between two servers, you will be asked to enter a password for your account on the remote server. You can skip the -e flag and rsync will use a non-encrypted connection to transfer data and login credentials.

Note that the SSH connection is established on the default SSH port, port 22. If your remote SSH server runs on a port other than 22, then you can use a slightly modified version of the preceding command as follows:

rsync -azP -e "ssh -p port_number" source destination

Anther common option is --exclude, which specifies the pattern for file names to be excluded. If you need to specify multiple exclusion patterns, then you can specify all such patterns in a text file and include that file in command with the options --exclude-from=filename. Similarly, if you need to include some specific files only, you can specify the inclusion pattern with options --include=pattern or --include-from=filename.

Exclude a single file or files matching with a single pattern:

$ rsync -azP --exclude 'dir*' source/ destination/

Exclude a list of patterns or file names:

$ rsync -azP --exclude-from 'exclude-list.txt' source/ destination/

By default, Rsync does not delete destination files, even if they are deleted from the source location. You can override this behavior with a --delete flag. You can create a backup of these files before deleting them. Use the --backup and --backup-dir options to enable backups. To delete files from the source directory, you can use the --remove-source-files flag. Another handy option is --dry-run, which simulates a transfer with the given flags and displays the output, but does not modify any files. You should use --dry-run before using any deletion flags.

Use this to remove source files with --dry-run:

$ rsync --dry-run --remove-source-files -azP source/  destination/

There's more…

Rsync is a great tool to quickly synchronize the files between source and destination, but it does not provide bidirectional synchronization. It means the changes are synchronized from source to destination and not vice versa. If you need bi-directional synchronization, you can use another utility, Unison. You can install Unison on Debian systems with the following command:

$ sudo apt-get -y install unison

Once installed, Unison is very similar to Rsync and can be executed as follows:

$ unison /home/ubuntu/documents ssh://10.0.2.56//home/ubuntu/documents

You can get more information about Unison in the manual pages with the following command:

$ man unison

If you wish to have your own Dropbox-like mirroring tool which continuously monitors for local file changes and quickly replicates them to network storage, then you can use Lsyncd. Lsyncd is a live synchronization or mirroring tool, which monitors the local directory tree for any events (with inotify and fsevents), and then after few seconds spawns a synchronization process to mirror all changes to a remote location. By default, Lsyncd uses Rsync for synchronization.

As always, Lsyncd is available in the Ubuntu package repository and can be installed with a single command, as follows:

$ sudo apt-get install lsyncd

To get more information about Lsyncd, check the manual pages with the following command:

$ man lsyncd

There's more…

Rsync is a great tool to quickly synchronize the files between source and destination, but it does not provide bidirectional synchronization. It means the changes are synchronized from source to destination and not vice versa. If you need bi-directional synchronization, you can use another utility, Unison. You can install Unison on Debian systems with the following command:

$ sudo apt-get -y install unison

Once installed, Unison is very similar to Rsync and can be executed as follows:

$ unison /home/ubuntu/documents ssh://10.0.2.56//home/ubuntu/documents

You can get more information about Unison in the manual pages with the following command:

$ man unison

If you wish to have your own Dropbox-like mirroring tool which continuously monitors for local file changes and quickly replicates them to network storage, then you can use Lsyncd. Lsyncd is a live synchronization or mirroring tool, which monitors the local directory tree for any events (with inotify and fsevents), and then after few seconds spawns a synchronization process to mirror all changes to a remote location. By default, Lsyncd uses Rsync for synchronization.

As always, Lsyncd is available in the Ubuntu package repository and can be installed with a single command, as follows:

$ sudo apt-get install lsyncd

To get more information about Lsyncd, check the manual pages with the following command:

$ man lsyncd

Performance tuning the Samba server

In this recipe, we will look at Samba configuration parameters in order to get optimum performance out of your Samba installation.

Getting ready

You will need root access or an account with sudo privileges.

It is assumed that you have installed the Samba server and it is properly working.

How to do it…

Open the Samba configuration file located at /etc/samba/smb.conf:
```
$ sudo vi /etc/samba/smb.conf
```

Add or edit the following options under the global section of the configuration file:

[global]
log level = 1
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
read raw = Yes
write raw = Yes
strict locking = No
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes
aio read size = 16384
aio write size = 16384
use sendfile = true

Save the configuration file and restart the Samba service:
```
$ sudo service smbd restart
```

How it works…

The Samba server provides various configuration parameters. It uses TCP sockets to connect with clients and for data transfer. You should compare Samba's performance with similar TCP services such as FTP.

The preceding example lists some commonly used configuration options for Samba. Some of these options may work for you and some of them may not. The latest Samba version ships with default values for these options that work fairly well for common network conditions. As always, test these options one at a time or in a group, and benchmark each modification to get optimum performance.

The explanation for the preceding is as follows:

log level: The default log level is set to 0. Samba produces a lot of debugging information and writing all this to disk is a slow operation. Increasing the log level results in increased logs and poor performance. Unless you are debugging the server, it is good to have the log level set to the lowest value.
socket options: These are the TCP/IP stack level options.
read raw and write raw: These options enable Samba to use large read and writes to a network up to 64 KB in a single request. Some older clients may have issues with raw reads and writes. Check your setup before using these options.
dead time and so_keepalive: These options set periodic checks for dead connections and close such connections and free unused memory.
oplocks: This allows clients to cache files locally and results in overall performance improvement. The default setting disables oplocks.
aio read size and aio write size: This Asynchronous IO (AIO) allows Samba to read and write asynchronously when a file's size is bigger than the specified size values.

You can find various other options and respective explanations in the Samba manual pages. Use the following command to open the manual pages on your server:

$ man smbd

Getting ready

You will need root access or an account with sudo privileges.

It is assumed that you have installed the Samba server and it is properly working.

How to do it…

Open the Samba configuration file located at /etc/samba/smb.conf:
```
$ sudo vi /etc/samba/smb.conf
```

Add or edit the following options under the global section of the configuration file:

[global]
log level = 1
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
read raw = Yes
write raw = Yes
strict locking = No
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes
aio read size = 16384
aio write size = 16384
use sendfile = true

Save the configuration file and restart the Samba service:
```
$ sudo service smbd restart
```

How it works…

The Samba server provides various configuration parameters. It uses TCP sockets to connect with clients and for data transfer. You should compare Samba's performance with similar TCP services such as FTP.

The preceding example lists some commonly used configuration options for Samba. Some of these options may work for you and some of them may not. The latest Samba version ships with default values for these options that work fairly well for common network conditions. As always, test these options one at a time or in a group, and benchmark each modification to get optimum performance.

The explanation for the preceding is as follows:

log level: The default log level is set to 0. Samba produces a lot of debugging information and writing all this to disk is a slow operation. Increasing the log level results in increased logs and poor performance. Unless you are debugging the server, it is good to have the log level set to the lowest value.
socket options: These are the TCP/IP stack level options.
read raw and write raw: These options enable Samba to use large read and writes to a network up to 64 KB in a single request. Some older clients may have issues with raw reads and writes. Check your setup before using these options.
dead time and so_keepalive: These options set periodic checks for dead connections and close such connections and free unused memory.
oplocks: This allows clients to cache files locally and results in overall performance improvement. The default setting disables oplocks.
aio read size and aio write size: This Asynchronous IO (AIO) allows Samba to read and write asynchronously when a file's size is bigger than the specified size values.

You can find various other options and respective explanations in the Samba manual pages. Use the following command to open the manual pages on your server:

$ man smbd

How to do it…

Open the Samba configuration file located at /etc/samba/smb.conf:
```
$ sudo vi /etc/samba/smb.conf
```

Add or edit the following options under the global section of the configuration file:

[global]
log level = 1
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
read raw = Yes
write raw = Yes
strict locking = No
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes
aio read size = 16384
aio write size = 16384
use sendfile = true

Save the configuration file and restart the Samba service:
```
$ sudo service smbd restart
```

How it works…

The Samba server provides various configuration parameters. It uses TCP sockets to connect with clients and for data transfer. You should compare Samba's performance with similar TCP services such as FTP.

The preceding example lists some commonly used configuration options for Samba. Some of these options may work for you and some of them may not. The latest Samba version ships with default values for these options that work fairly well for common network conditions. As always, test these options one at a time or in a group, and benchmark each modification to get optimum performance.

The explanation for the preceding is as follows:

log level: The default log level is set to 0. Samba produces a lot of debugging information and writing all this to disk is a slow operation. Increasing the log level results in increased logs and poor performance. Unless you are debugging the server, it is good to have the log level set to the lowest value.
socket options: These are the TCP/IP stack level options.
read raw and write raw: These options enable Samba to use large read and writes to a network up to 64 KB in a single request. Some older clients may have issues with raw reads and writes. Check your setup before using these options.
dead time and so_keepalive: These options set periodic checks for dead connections and close such connections and free unused memory.
oplocks: This allows clients to cache files locally and results in overall performance improvement. The default setting disables oplocks.
aio read size and aio write size: This Asynchronous IO (AIO) allows Samba to read and write asynchronously when a file's size is bigger than the specified size values.

You can find various other options and respective explanations in the Samba manual pages. Use the following command to open the manual pages on your server:

$ man smbd

How it works…

The Samba server provides various configuration parameters. It uses TCP sockets to connect with clients and for data transfer. You should compare Samba's performance with similar TCP services such as FTP.

The preceding example lists some commonly used configuration options for Samba. Some of these options may work for you and some of them may not. The latest Samba version ships with default values for these options that work fairly well for common network conditions. As always, test these options one at a time or in a group, and benchmark each modification to get optimum performance.

The explanation for the preceding is as follows:

log level: The default log level is set to 0. Samba produces a lot of debugging information and writing all this to disk is a slow operation. Increasing the log level results in increased logs and poor performance. Unless you are debugging the server, it is good to have the log level set to the lowest value.
socket options: These are the TCP/IP stack level options.
read raw and write raw: These options enable Samba to use large read and writes to a network up to 64 KB in a single request. Some older clients may have issues with raw reads and writes. Check your setup before using these options.
dead time and so_keepalive: These options set periodic checks for dead connections and close such connections and free unused memory.
oplocks: This allows clients to cache files locally and results in overall performance improvement. The default setting disables oplocks.
aio read size and aio write size: This Asynchronous IO (AIO) allows Samba to read and write asynchronously when a file's size is bigger than the specified size values.

You can find various other options and respective explanations in the Samba manual pages. Use the following command to open the manual pages on your server:

$ man smbd

Troubleshooting the Samba server

In this recipe, we will look at the various tools available for troubleshooting Samba shares.

How to do it…

Samba troubleshooting can be separated in to three parts: network connectivity, Samba process issues, and Samba configuration issues. We will go through each of them step by step. As a first step for troubleshooting, let's start with network testing.

Checking network connectivity

Follow these steps to check network connectivity:

Send ping requests to the Samba server to check network connectivity:
```
$ ping samba-server-ip
```
Check name resolution. Ping the Samba server by its name. Windows uses netbios for name resolution:
```
$ ping samba-server-name
```
Check the Samba configuration for network restrictions. Temporarily open Samba to all hosts.
Use tcpdump to check Samba network communication. Start tcpdump as follows and let it run for some time while accessing the Samba server from clients. All packets will be logged in a file named tcpdump in the current directory:
```
$ sudo tcpdump -p -s 0 -w tcpdumps port 445 or port 139
```
If you know the client IP address, you can filter tcpdumps with the following command:
```
$ sudo tcpdump -s 0 -w tcpdumps host client_IP
```
Connect to the Samba process with telnet:
```
$ echo "hello" | telnet localhost 139
```
Check whether your Samba server uses a firewall. If so, check the allowed ports on your firewall. If the firewall is on, make sure you have allowed the Samba ports as follows:
Try connecting to FTP or a similar TCP service on the Samba server. This may identify the problems with the TCP stack.
Use nmblookup to test netbios name resolution for Windows systems.

Checking the Samba service

Follow these steps to check Samba service:

Check whether the Samba service has started properly:
```
$ sudo service samba status
```
Use netstat to check the Samba daemon is listening on the network:
```
$ sudo netstat -plutn
```
Use ps to check the Samba processes. Look for the process name, smbd, in the output of the following command:
```
$ ps aux
```
Use strace to view the Samba process logs. This will list all filesystem activities by smbd process:
```
$ strace smbd
```

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.
Increase the log level to get more debugging information:
```
[global]
log level = 3
```
Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:
```
[global]
    log level = 0
    log file = /var/log/samba/log.%m
    include = /etc/samba/smb.conf.%m
```

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1
[global]
log level = 3

Similarly, you can create separate logs for each Samba user:

[global]
    log level = 0
    log file = /var/log/samba/log.%u
    include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

How to do it…

Samba troubleshooting can be separated in to three parts: network connectivity, Samba process issues, and Samba configuration issues. We will go through each of them step by step. As a first step for troubleshooting, let's start with network testing.

Checking network connectivity

Follow these steps to check network connectivity:

Send ping requests to the Samba server to check network connectivity:
```
$ ping samba-server-ip
```
Check name resolution. Ping the Samba server by its name. Windows uses netbios for name resolution:
```
$ ping samba-server-name
```
Check the Samba configuration for network restrictions. Temporarily open Samba to all hosts.
Use tcpdump to check Samba network communication. Start tcpdump as follows and let it run for some time while accessing the Samba server from clients. All packets will be logged in a file named tcpdump in the current directory:
```
$ sudo tcpdump -p -s 0 -w tcpdumps port 445 or port 139
```
If you know the client IP address, you can filter tcpdumps with the following command:
```
$ sudo tcpdump -s 0 -w tcpdumps host client_IP
```
Connect to the Samba process with telnet:
```
$ echo "hello" | telnet localhost 139
```
Check whether your Samba server uses a firewall. If so, check the allowed ports on your firewall. If the firewall is on, make sure you have allowed the Samba ports as follows:
Try connecting to FTP or a similar TCP service on the Samba server. This may identify the problems with the TCP stack.
Use nmblookup to test netbios name resolution for Windows systems.

Checking the Samba service

Follow these steps to check Samba service:

Check whether the Samba service has started properly:
```
$ sudo service samba status
```
Use netstat to check the Samba daemon is listening on the network:
```
$ sudo netstat -plutn
```
Use ps to check the Samba processes. Look for the process name, smbd, in the output of the following command:
```
$ ps aux
```
Use strace to view the Samba process logs. This will list all filesystem activities by smbd process:
```
$ strace smbd
```

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.
Increase the log level to get more debugging information:
```
[global]
log level = 3
```
Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:
```
[global]
    log level = 0
    log file = /var/log/samba/log.%m
    include = /etc/samba/smb.conf.%m
```

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1
[global]
log level = 3

Similarly, you can create separate logs for each Samba user:

[global]
    log level = 0
    log file = /var/log/samba/log.%u
    include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

Checking network connectivity

Follow these steps to check network connectivity:

Send ping requests to the Samba server to check network connectivity:
```
$ ping samba-server-ip
```
Check name resolution. Ping the Samba server by its name. Windows uses netbios for name resolution:
```
$ ping samba-server-name
```
Check the Samba configuration for network restrictions. Temporarily open Samba to all hosts.
Use tcpdump to check Samba network communication. Start tcpdump as follows and let it run for some time while accessing the Samba server from clients. All packets will be logged in a file named tcpdump in the current directory:
```
$ sudo tcpdump -p -s 0 -w tcpdumps port 445 or port 139
```
If you know the client IP address, you can filter tcpdumps with the following command:
```
$ sudo tcpdump -s 0 -w tcpdumps host client_IP
```
Connect to the Samba process with telnet:
```
$ echo "hello" | telnet localhost 139
```
Check whether your Samba server uses a firewall. If so, check the allowed ports on your firewall. If the firewall is on, make sure you have allowed the Samba ports as follows:
Try connecting to FTP or a similar TCP service on the Samba server. This may identify the problems with the TCP stack.
Use nmblookup to test netbios name resolution for Windows systems.

Checking the Samba service

Follow these steps to check Samba service:

Check whether the Samba service has started properly:
```
$ sudo service samba status
```
Use netstat to check the Samba daemon is listening on the network:
```
$ sudo netstat -plutn
```
Use ps to check the Samba processes. Look for the process name, smbd, in the output of the following command:
```
$ ps aux
```
Use strace to view the Samba process logs. This will list all filesystem activities by smbd process:
```
$ strace smbd
```

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.
Increase the log level to get more debugging information:
```
[global]
log level = 3
```
Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:
```
[global]
    log level = 0
    log file = /var/log/samba/log.%m
    include = /etc/samba/smb.conf.%m
```

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1
[global]
log level = 3

Similarly, you can create separate logs for each Samba user:

[global]
    log level = 0
    log file = /var/log/samba/log.%u
    include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

See also

Samba docs troubleshooting at https://www.samba.org/samba/docs/using_samba/ch12.html

Checking the Samba service

Follow these steps to check Samba service:

Check whether the Samba service has started properly:
```
$ sudo service samba status
```
Use netstat to check the Samba daemon is listening on the network:
```
$ sudo netstat -plutn
```
Use ps to check the Samba processes. Look for the process name, smbd, in the output of the following command:
```
$ ps aux
```
Use strace to view the Samba process logs. This will list all filesystem activities by smbd process:
```
$ strace smbd
```

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.
Increase the log level to get more debugging information:
```
[global]
log level = 3
```
Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:
```
[global]
    log level = 0
    log file = /var/log/samba/log.%m
    include = /etc/samba/smb.conf.%m
```

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1
[global]
log level = 3

Similarly, you can create separate logs for each Samba user:

[global]
    log level = 0
    log file = /var/log/samba/log.%u
    include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

See also

Samba docs troubleshooting at https://www.samba.org/samba/docs/using_samba/ch12.html

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.
Increase the log level to get more debugging information:
```
[global]
log level = 3
```
Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:
```
[global]
    log level = 0
    log file = /var/log/samba/log.%m
    include = /etc/samba/smb.conf.%m
```

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1
[global]
log level = 3

Similarly, you can create separate logs for each Samba user:

[global]
    log level = 0
    log file = /var/log/samba/log.%u
    include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

See also

Samba docs troubleshooting at https://www.samba.org/samba/docs/using_samba/ch12.html

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:
```
$ sudo pdbedit -L
```
Check the shares with the smbtree command:
Use the testparm command to find any errors in the Samba configuration:
```
$ testparm
```
Check for allowed users and group names. Make sure that group names start with the @ symbol.
Back up your configuration files and then use minimal configuration to test Samba:
```
[global]
    workgroup = WORKGROUP
    security = user
    browsable = yes
[temp]
    path = /tmp
    public = yes
```
Note
Publicly writable directories are not good for server security. Remove the preceding configuration as soon as testing is finished.
Test your configuration with smbcclient. It should list all Samba shares:
```
$ smbclient -L localhost -U%
```

See also

Samba docs troubleshooting at https://www.samba.org/samba/docs/using_samba/ch12.html

Installing the Network File System

Network File System (NFS) is a distributed filesystem protocol that allows clients to access remote files and directories as if they are available on the local system. This allows client systems to leverage large centrally shared storage. Users can access the same data from any system across the network. A typical setup for NFS includes a server that runs the NFS daemon, nfsd, and lists (export) files and directories to be shared. A client system can mount these exported directories as their local file system.

In this recipe, we will learn how to install the NFS server and client systems.

Getting ready

You will need two Ubuntu systems: one as a central NFS server and another as a client. For this recipe, we will refer to the NFS server with the name Host and the NFS client with the name Client. The following is an example IP address configuration for the Host and Client systems:

Host - 10.0.2.60
Client - 10.0.2.61

You will need access to a root account on both servers, or at least an account with sudo privileges.

How to do it…

Follow these steps to install NFS:

First, we need to install the NFS server:

$ sudo apt-get update
$ sudo apt-get install nfs-kernel-server

Create the directories to be shared:
```
$ sudo mkdir /var/nfs
```
Add this directory to NFS exports under /etc/exports:
```
$ sudo nano /etc/exports
```
Add the following line to /etc/exports:
```
/var/nfs	*(rw,sync,no_subtree_check)
```
Save and close the exports file.

Now, restart the NFS service:

$ sudo service nfs-kernel-server restart

Next, we need to configure the client system to access NFS shares.
Create a mount point for NFS shares.

Install the nfs-common package on the client side:

$ sudo apt-get install nfs-common
$ sudo mkdir -p /var/nfsshare

Mount the NFS shared directory on the newly-created mount point:
```
$ sudo mount 10.0.2.60:/var/nfs /var/nfsshare
```
Confirm the mounted share with the following command:
```
$ mount -t nfs
```
Now, change the directory to /var/nfsshare, and you are ready to use NFS.

How it works…

In the preceding example, we have installed the NFS server and then created a directory that will share with clients over the network. The configuration file /etc/exports contains all NFS shared directories. The syntax to add new exports is as follows:

directory_to_share   client_IP_or_name(option1, option2, option..n)

The options used in exports are as follows:

rw: This enables read/write access. You can enable read-only access with the ro option.
sync: This forces the NFS server to write changes to disk before replying to requests. sync is the default option; you can enable async operations by explicitly stating async. Async operations may get a little performance boost but at the cost of data integrity.
no_subtree_check: This disables subtree checking, which provides more stable and reliable NFS shares.

You can check the exports documentation for more export options. Use the man command to open the exports manual pages, as follows:

$ man exports

In the preceding example, we have used the mount command to mount the NFS share. Once the client system has restarted, this mount will be removed. To remount the NFS share on each reboot, you can add the following line to /etc/fstab file:

10.0.2.60:/var/nfs   /var/nfsshare   nfs4    _netdev,auto  0  0

To mount all shares exported by the NFS server, you can use the following command:

$ sudo mount 10.0.2.60:/ /var/nfsshare

There's more…

NFS 4.1 adds support for pNFS, which enables clients to access the storage device directly and in parallel. This architecture eliminates scalability and performance issues with NFS deployments.

Getting ready

You will need two Ubuntu systems: one as a central NFS server and another as a client. For this recipe, we will refer to the NFS server with the name Host and the NFS client with the name Client. The following is an example IP address configuration for the Host and Client systems:

Host - 10.0.2.60
Client - 10.0.2.61

You will need access to a root account on both servers, or at least an account with sudo privileges.

How to do it…

Follow these steps to install NFS:

First, we need to install the NFS server:

$ sudo apt-get update
$ sudo apt-get install nfs-kernel-server

Create the directories to be shared:
```
$ sudo mkdir /var/nfs
```
Add this directory to NFS exports under /etc/exports:
```
$ sudo nano /etc/exports
```
Add the following line to /etc/exports:
```
/var/nfs	*(rw,sync,no_subtree_check)
```
Save and close the exports file.

Now, restart the NFS service:

$ sudo service nfs-kernel-server restart

Next, we need to configure the client system to access NFS shares.
Create a mount point for NFS shares.

Install the nfs-common package on the client side:

$ sudo apt-get install nfs-common
$ sudo mkdir -p /var/nfsshare

Mount the NFS shared directory on the newly-created mount point:
```
$ sudo mount 10.0.2.60:/var/nfs /var/nfsshare
```
Confirm the mounted share with the following command:
```
$ mount -t nfs
```
Now, change the directory to /var/nfsshare, and you are ready to use NFS.

How it works…

In the preceding example, we have installed the NFS server and then created a directory that will share with clients over the network. The configuration file /etc/exports contains all NFS shared directories. The syntax to add new exports is as follows:

directory_to_share   client_IP_or_name(option1, option2, option..n)

The options used in exports are as follows:

rw: This enables read/write access. You can enable read-only access with the ro option.
sync: This forces the NFS server to write changes to disk before replying to requests. sync is the default option; you can enable async operations by explicitly stating async. Async operations may get a little performance boost but at the cost of data integrity.
no_subtree_check: This disables subtree checking, which provides more stable and reliable NFS shares.

You can check the exports documentation for more export options. Use the man command to open the exports manual pages, as follows:

$ man exports

In the preceding example, we have used the mount command to mount the NFS share. Once the client system has restarted, this mount will be removed. To remount the NFS share on each reboot, you can add the following line to /etc/fstab file:

10.0.2.60:/var/nfs   /var/nfsshare   nfs4    _netdev,auto  0  0

To mount all shares exported by the NFS server, you can use the following command:

$ sudo mount 10.0.2.60:/ /var/nfsshare

There's more…

NFS 4.1 adds support for pNFS, which enables clients to access the storage device directly and in parallel. This architecture eliminates scalability and performance issues with NFS deployments.

How to do it…

Follow these steps to install NFS:

First, we need to install the NFS server:

$ sudo apt-get update
$ sudo apt-get install nfs-kernel-server

Create the directories to be shared:
```
$ sudo mkdir /var/nfs
```
Add this directory to NFS exports under /etc/exports:
```
$ sudo nano /etc/exports
```
Add the following line to /etc/exports:
```
/var/nfs	*(rw,sync,no_subtree_check)
```
Save and close the exports file.

Now, restart the NFS service:

$ sudo service nfs-kernel-server restart

Next, we need to configure the client system to access NFS shares.
Create a mount point for NFS shares.

Install the nfs-common package on the client side:

$ sudo apt-get install nfs-common
$ sudo mkdir -p /var/nfsshare

Mount the NFS shared directory on the newly-created mount point:
```
$ sudo mount 10.0.2.60:/var/nfs /var/nfsshare
```
Confirm the mounted share with the following command:
```
$ mount -t nfs
```
Now, change the directory to /var/nfsshare, and you are ready to use NFS.

How it works…

In the preceding example, we have installed the NFS server and then created a directory that will share with clients over the network. The configuration file /etc/exports contains all NFS shared directories. The syntax to add new exports is as follows:

directory_to_share   client_IP_or_name(option1, option2, option..n)

The options used in exports are as follows:

rw: This enables read/write access. You can enable read-only access with the ro option.
sync: This forces the NFS server to write changes to disk before replying to requests. sync is the default option; you can enable async operations by explicitly stating async. Async operations may get a little performance boost but at the cost of data integrity.
no_subtree_check: This disables subtree checking, which provides more stable and reliable NFS shares.

You can check the exports documentation for more export options. Use the man command to open the exports manual pages, as follows:

$ man exports

In the preceding example, we have used the mount command to mount the NFS share. Once the client system has restarted, this mount will be removed. To remount the NFS share on each reboot, you can add the following line to /etc/fstab file:

10.0.2.60:/var/nfs   /var/nfsshare   nfs4    _netdev,auto  0  0

To mount all shares exported by the NFS server, you can use the following command:

$ sudo mount 10.0.2.60:/ /var/nfsshare

There's more…

NFS 4.1 adds support for pNFS, which enables clients to access the storage device directly and in parallel. This architecture eliminates scalability and performance issues with NFS deployments.

How it works…

In the preceding example, we have installed the NFS server and then created a directory that will share with clients over the network. The configuration file /etc/exports contains all NFS shared directories. The syntax to add new exports is as follows:

directory_to_share   client_IP_or_name(option1, option2, option..n)

The options used in exports are as follows:

rw: This enables read/write access. You can enable read-only access with the ro option.
sync: This forces the NFS server to write changes to disk before replying to requests. sync is the default option; you can enable async operations by explicitly stating async. Async operations may get a little performance boost but at the cost of data integrity.
no_subtree_check: This disables subtree checking, which provides more stable and reliable NFS shares.

You can check the exports documentation for more export options. Use the man command to open the exports manual pages, as follows:

$ man exports

In the preceding example, we have used the mount command to mount the NFS share. Once the client system has restarted, this mount will be removed. To remount the NFS share on each reboot, you can add the following line to /etc/fstab file:

10.0.2.60:/var/nfs   /var/nfsshare   nfs4    _netdev,auto  0  0

To mount all shares exported by the NFS server, you can use the following command:

$ sudo mount 10.0.2.60:/ /var/nfsshare

There's more…

NFS 4.1 adds support for pNFS, which enables clients to access the storage device directly and in parallel. This architecture eliminates scalability and performance issues with NFS deployments.

There's more…

NFS 4.1 adds support for pNFS, which enables clients to access the storage device directly and in parallel. This architecture eliminates scalability and performance issues with NFS deployments.

You're reading from Linux: Powerful Server Administration Recipes for CentOS 7, RHEL 7, and Ubuntu Server Administration

Table of Contents (6) Chapters

Chapter 6. Network Storage

Introduction

Installing the Samba server

Getting ready

How to do it…

How it works…

There's more…

Tools for personal file sharing

See also

Getting ready

How to do it…

How it works…

There's more…

Tools for personal file sharing

See also

How to do it…

How it works…

There's more…

Tools for personal file sharing

See also

How it works…

There's more…

Tools for personal file sharing

See also

There's more…

Tools for personal file sharing

See also

Tools for personal file sharing

See also

Adding users to the Samba server

Getting ready

How to do it…

How it works…

There's more…

See also

Getting ready

How to do it…

How it works…

There's more…

See also

How to do it…

How it works…

There's more…

See also

How it works…

There's more…

See also

There's more…

See also

See also

Installing the secure FTP server

Getting ready

How to do it…

How it works…

There's more…

See also

Getting ready

How to do it…

How it works…

There's more…

See also

How to do it…

How it works…

There's more…

See also

How it works…

There's more…

See also

There's more…

See also

See also

Synchronizing files with Rsync

How to do it…

How it works…

There's more…

See also

How to do it…

How it works…