NAS4Free setup for a Windows share

Nas4freeNAS4Free is open source software used to create a Network Attached Storage server.  By repurposing an old desktop PC and a handful of disk drives you can have an excellent NAS server that can be used by any of the devices on your network.  NAS4Free also has a number of other optional services including FTP, Torrent, Web server and Media server.  When you go to the NAS4Free web site there will be a number of considerations you will need to address for the hardware.  The entire NAS4Free software OS is recommended to be installed on a 8GB USB Thumb drive.  The installation and configuration is relatively simple however, creating a Windows Share drive that you can mount as a drive letter is a little tricky.

Login to NAS4Free server

After the installation is completed the NAS4Free console will let you know the IP address of the server, in this example it is as determine by the network DCHP server.  Open a browser to this page to get the login


Setting up ZFS filesystem

It is recommended that you create a ZFS file system to take advantage of multiple disks, in this example there are two 4TB physical drives in the desktop server.


The main screen of NAS4Free displays some basic information about the system and its utilization.  The ZFS is located under the (Disks) menu selection.

The first step in a ZFS file system is to create a virtual drive from your collection of physical disks.



The Type of Virtual Disk indicates how you want to configure the drives to recover from errors.  In this example (Stripe) was selected to get the maximum amount of space.  The Virtual Disk name is (VD1)

The second step is to create a Pool that we can use to set up the Windows share from.


Now we have created a Pool called (Open01) from the Virtual Disk (VD1).

Configure CIFS/SMB service

Third step which is the tricky one is to configure the CIFS/SMB Service on NAS4Free.  This is required for creating Windows Shares.  This is done under the (Services) menu selection.


Fourth step is to configure the CIFS/SMB service.

The defaults for the CIFS/SMB service are typically good for most installations.


The Max Protocol was set to SMB3 to allow use of Windows 8.x systems to access the shared drive.  The NetBIOS name is actually the server name used when creating the Windows share.

Fifth step is to create the shares by clicking on the SHARE tab on the top of the previous image


The Name (ShareNas4Free) is the windows share name.  You can create multiple share names and isolate shares for specific purposes.   The shares come from the Pool we created called (Open01).

Create Windows Share

Sixth step is to go to the Windows Explorer on one of the systems you want to use the NAS4Free share drive on and created a mapped drive.


Seventh step is to locate the shared drive.  You can try to use the (Browse…) button but sometimes the newly created share is not immediatley available.  So the alternative method is to enter the share name in the Folder field.  In this example the share name is \\NAS4Free\ShareNAS4Free.


When you are successful on getting the NAS4Free share name entered you will be prompted for a NAS4Fee user to access the share.  If you haven’t created a special user for this share you can use the default NAS4Free admin user (Root).


In this example the (W:) drive was mapped to the \\Nas4free server and the (ShareNas4Free) share.  Now you use this drive just like any other drive on your windows system.










SQL Server Column encryption

LockItThere are times when you need to encrypt just a column in a database table.  Most posts on this topic relate to a password that needs to be encrypted.  This example highlights encrypting Protected Health Information also known as PHI.  PHI fields can include medical id, beneficiary id, Medicaid id or address information.   Private information PI can include social security numbers, driver license id or inmate id.   Both PHI and PI information can and should be encrypted.

Some are fans of encrypting within the application (C#, Python, Ruby, .NET) others prefer to encrypt at the database engine level.  Encryption requires processing cycles at application, database or both levels, so choose carefully where you encrypt/de-encrypt.  This example will show how to perform encryption at the database level for a single column.

Encryption algorithms vary in level of encryption but basically the deeper the encryption the more processing cycles you will use.   In this example, we will use the RSA_2048 encryption algorithm.  This example will also be using an Asymmetric key (two parts) one part of the key embedded in the database, the other part external to the database and know to the developer.    If the PHI/PI data is copied out of the database in its encrypted form it can NOT be decoded because the database key is not available to whoever got the data.    If somehow the person has access to the database they can NOT decode the data without the developer key.   This protects the PHI/PI on either side of the database wall.  This type of encryption is not bulletproof if someone has access to the database and gets the developer key they could decode the PHI/PI.

SQL developers will frequently use Stored Procedures (SP) to code up access to the database for the applications.  If the developer key is used in any of those SP’s it becomes a risk because another database user could use this key to decode PHI/PI.   One way around this risk is to have the developer key passed as a parameter to the SP from the application.  This means someone would need to have both application and database access to decode.

Create an Asymmetric Key in the database

The first step is to create the Asym key in the database.  Connect to your server and login with a user who has admin access to the database.  Create a developer key that is only going to be known to the developer.

Create a Query to show how the Encryption Works

To show how the encryption works we will do a query and encrypt the Column Beneficiary ID which is considered to be PHI.  Please notice that the developer key is not needed in order to encrypt data.

Line 1: The database key we created is turned into an integer variable which will be used to encrypt the Beneficiary ID
Line 6: If we displayed this column it would be bad because this is the PHI column
Line 7: This is where the database key, now in @KEYID, will be used to encrypt the Beneficiary id

Encrypted Query Results

The results from this query are shown below, no PHI information is being displayed.


Notice that the (Encoded_BeneID) is an encrypted column and it is really long.  This de-identifies the Beneficiary ID which is considered PHI.   If this result were to be inserted into a table or converted to a file and sent to someone, it would still be secure.

Decrypt the Encrypted data

Making the assumption here that the encrypted data was loaded into a table named called BenePopulation we need to decrypt the Beneficiary ID.

Line 2: We get the database key
Line 5: We use the database key (@KEYID) and the developer key (S3cr3tStuff!) to decrypt the beneficiary id

More Secure Stored Procedure

Note: While this was nice and easy for a query it is not suggested that you code this into a stored procedure as this would reveal the super secret developer key.  To avoid this, the stored procedure (SP) we will create, will pass the developer key as a parameter to the SP.