Proxmox NAS Storage: Securing a Samba DAS
Richard Chamberlain
Posted on October 6, 2024
With the network and firewall rules configured, there are just a few final tasks to complete on the Samba server:
- Enhance Samba security
- Mount the DAS volumes on the server
While this may seem redundant given the firewall settings, the next step adds an extra layer of protection. We’ll limit access to the Samba server by specifying allowed hosts directly in the Samba configuration file. This ensures that only designated servers can connect, further tightening security.
Finalizing Samba Security
When we first set up the Samba server, we configured allowed users and set the minimum SMB protocol. Now, it’s time to finish securing the server by restricting which computers can access it using the hosts allow
directive in the Samba configuration.
Here’s how I’ve set up host access control:
Proxmox Share the Samba config file:
# 192.168.177.129 - Proxmox Backup Server
# 192.168.177.7 - Proxmox Server Management Port
# 192.168.178.0/24 - Proxmox VM Netork
# This also keeps my laptops off this share 192.168.166.0/24
hosts allow = 192.168.177.129 192.168.177.7 192.168.178.0/24
This configuration ensures that only the necessary servers can access the Samba pbe share. It also prevents my personal laptop, which are on the 192.168.166.0/24 subnet, from accessing these shares.
Media Share the Samba config file:
## 192.168.168.0/24 - Allow device on WI-FI to access media
## 192.168.166.66 - Allow personal desktop but stop work laptop access
## Proxmox server do not have access
hosts allow = 192.168.168.0/24 192.168.166.66
This configuration ensures that only the Wi-Fi devices can access the Samba media share, while also allowing my personal laptop to share access to the media.
Now, let’s move on to mounting the DAS volumes and securing them.
Mounting DAS Drives
The DAS has five bays, and two of the drives are being mounted for Samba use. Since these drives were previously used on a Linux server and already contain data, there's no need for partitioning or formatting.
Information Needed to Mount the Drives
To mount a drive on a Linux system using the /etc/fstab
file, you’ll need the following details:
- What is being mounted – The device name or UUID of the drive
- Where it is being mounted – The target directory (mount point)
- File system type – The type of file system (e.g., ext4, xfs)
- Mount options – Specific options for mounting (e.g., defaults, noatime)
-
Dump – Whether the filesystem should be backed up by the
dump
command -
Pass – The order in which filesystems should be checked by
fsck
(file system check)
To mount the drives correctly, I needed to gather some essential information, such as the UUID and file system type (FSTYPE) of the drives. Here's how I did it:
Identifying the Drives and File System Types
I used the lsblk
(list block devices) command to display the hard drives and their details, including the UUID and file system type. Here’s an example of the output:
lsblk -f # returns the following
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
sdb
sdc
sdd
└─sdd1 ext4 1.0 3208c81f-0714-42bb-a8fc-adfbfc4ca336
sde
└─sde1 ext4 1.0 65a350ce-4548-4ef1-86bb-e48965924224
Note: This project uses UUIDs instead of device names for added stability and security.
Drives can be mounted using either the device name (e.g.,
/dev/sdd1
) or the UUID (e.g.,3208c81f-0714-42bb-a8fc-adfbfc4ca336
). However, device names are assigned at boot and can change if new disks or partitions are added or removed.The UUID, on the other hand, is a unique identifier assigned to a partition and only changes when the partition is recreated. This ensures that even if partitions or disks are added or removed, the UUID remains the same.
Additionally, using the UUID ensures that if a drive is removed from the DAS and replaced with a different one, the system will not automatically load the new drive. While this adds a layer of security, it also means that the system won’t support hotswapping drives without further configuration.
Setting Up Mount Point Options
Now, let’s configure the options for the mount points. Since this system will be used as storage for a NAS and is non-production, I’ve opted for security over performance. After reviewing the available options, the following settings seem to fit the requirements:
- atime: Ensures file access timestamps are updated. This can improve security by tracking file access but may impact performance in some cases.
- noexec: Prevents the execution of binaries on this mount, adding an extra layer of security.
- nodev: Disallows the creation or usage of device files, which enhances security on the storage volume.
- errors=remount-ro: If any errors are detected on the filesystem, this option automatically remounts the filesystem as read-only, preventing further issues.
Finally, the seutp for dump and pass
Configuring Dump and Pass
Since the dump
command is not installed on the server, I’ve set the dump value to 0
, meaning the filesystem will not be included in backup routines via dump
.
For the pass
value, I’ve chosen to set it to 2
, which ensures that the mounted filesystems will be checked during boot. While this will slightly slow down the boot process, it’s acceptable for a back-end system that isn’t rebooted frequently.
The possible values for pass
are:
- 0: Do not check the filesystem at boot.
-
1: Check the filesystem first, typically used for the root (
/
) filesystem. - 2: Check the filesystem after the root filesystem has been checked.
Updating the fstab File
During boot, Linux systems reference the /etc/fstab
file to mount additional hard drives. To finalize this project, let’s bring everything together and add the appropriate entries to the fstab
file.
Here’s how we’ll define the lines based on the information we’ve gathered:
## From DAS bay 1
UUID=3208c81f-0714-42bb-a8fc-adfbfc4ca336 /srv/nas_storage/media ext4 atime,atime,nodev,noexec,errors=remount-ro 0 0
## From DAS bay 2
UUID=65a350ce-4548-4ef1-86bb-e48965924224 /srv/nas_storage/pve ext4 atime,nodev,noexec,commit=600,errors=remount-ro 0 0
With all the changes in place, I rebooted the server and tested the mounts—they all worked perfectly.
Looking back, if I were to do this again, I might choose a different device than the Orange Pi 5 Pro. The version of Debian available for it doesn't support Logical Volume Manager (LVM), which would have allowed me to combine the hard drives into a single large logical volume for better storage flexibility.
While the initial NAS setup took a few steps, adding additional shared folders in the future will be much simpler.
If you had a NAS, how would you use it?
Posted on October 6, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.