Jump to content

Secure Writing Strategy for UnRAID server using 'Write Once-Read Many' mode


Recommended Posts

The Problem

This all began when @lionelhutz made the following suggestion about increasing security for data on unRAID servers where the data storage is basically--- 'Write-once-read many'.

You could set all the user shares to Secure and share the cache drive as public. Then, navigate to cache and write the data in directories with the exact same name as the user shares. The mover will copy off the cache overnight and the data will be write protected. No need to add any users to the server if you do it this way.

For example, if you have a share called 'Music' then go to \\TOWER\cache and write the data to a directory called 'Music'. Then, the data will be moved to the array overnight and protected once it's on the array.

Then one of our unRAID users, @Siwat2545, actually got hit with a Ramsomware attack that inflected his unRAID server.  So that threat is far more than theoretical one!  It can and has happened!


@lionelhutz's basic scheme actually works.  However, the actual implementation turns out to be a bit more difficult than that.  First, most of the time, you are trying to do more then store data in the root of the share.  It will more likely be somewhere down a directory tree.  Second, the unRAID Mover function deletes the entire directory tree as it moves the files off of the cache to the array.   The combination of these two  issues requires that you have to recreate the paths to the location where you want to store the data on the array---  no misspellings  and no changes in capitalization (as Linux honors capitalization where Windows does not and this can create a big issue with files going 'missing' when viewed on a Windows client).  It is also very time consuming to upload a few files on different branches of a directory tree.  Fortunately, there are a couple of ways around this problem. 


I have prepared a PDF file with the complete set of step-by-step instructions for how I implemented a protection plan for my two servers.  It is attached as I think when you have a step-by-step plan, it best used by having a printed out copy to actually be able to check off each step as you complete.  I also encourage to read it first and gain a feeling for what you will be doing.

As I said, I have done both of my servers in the past week.  (I did the second one using the instructions so I could double-check that I hadn't missed anything.)  I also have some other thoughts that you might want to consider regarding security.

Thought 1


@lionelhutz pointed out this following area of concern:

If the cache is exposed as public then it would be a good idea to do backups of any of the cache only user shares, such as the appdata, Docker files, VM Images or domains.

Thought 2


I had a situation where I had User Share that I wanted to secure.  However, there was a folder in that share which was setup as a mapped drive on several different Windows computers.  A Windows' application was going to be opening those files on that mapped drive in a read-write mode.  (It was a personal information manager for phone numbers, addresses, mailing lists, etc. to which more than one person had to have access to.)  What I did was move those files to a new share which was set to "Public"  and then I made provisions to make sure it was backed up regularly to a "Secure"  Share. 

Thought 3


Even with this enhanced security added for the protection of the data on your unRAID server, there is still no protection for the physical hardware itself.  Fire, Lightening, Flooding and Massive Electric Power Surges are a real problems that are as important to consider as protecting your data from Malware.  You really need an off-site backup of any irreplaceable personal data to provide protection from these physical hazards. 

Thought 4


I mentioned earlier about there being more than one way to have a directory tree available for use on the Cache drive.  The second way would be for LimeTech to modify the Mover script with a switch which would allow the tree to remain after Mover has finished.  (Mover presently deletes the tree.  I saw somewhere that the original Mover didn't do this tree removal.  It would have deleted the files that it moved.)  To get the change to be made will probably require that a demonstrated large number of users have implement this data protection scheme and who then request that the necessary changes to Mover.

Thought 5


If you plan on manual moving the files from the cache drive to the secured array, you may be tempted to set the automated Mover to once a month in the Scheduler.  This could be a mistake.  Imagine the scenario where you put several files on the cache drive and  decided to wait to invoke the Mover until you put a few more files a bit later.  The 'bit later' never happens and now those files may sit there as long as a month (possibly totally unprotected) before they get moved.  There is no problem with Mover running without having any files to move.   

Thought 6


If you are looking for a file manager to do tasks like renaming files, deleting files, copying files between User Shares, you should have a good look at the  Krusader Docker.  I installed it and I would best describe as Windows Explorer on steroids.  Plus, you have to be logged into the unRAID GUI to launch it which is a security  plus and means that Krusader is running as the superuser root so you can work on Shares that are restricted to read only when accessed from SMB.  

There is an excellent YouTube describing how to install Krusader and some great tips on setting it for use on your unRAID server.  You can find it here:



Thought 7

To secure your unRAIDFlash Drive, you might consider stopping the Export of the Flash Drive using the 'SMB Security Settings' for theFlash Drive.  Updating of the unRAID OS and plugins is now usually handled via the GUI which eliminates the need for having to manually copy the upgrade files to the drive using SMB.  If you really need to access it, you simply re-enable the drive to gain access to it.  This approach seems to present few login issues than setting it to either 'Secure or 'Private'.


(I had initially set my Flash Drive to 'Secure' and found that making it secure and getting a user account to gain access to the Flash Drive resulted in login prompt to get access to any of the 'Public' shares on the server.  This is an issue with SMB and would happen even if you were using a Windows server!  Even after I had changed the Flash Drive back to 'Public', I was still getting bugged by the logon request.  Deleting the user finally resolved the problem.)


(And if you really think about it with the cache drive being shared as 'Public' and using Krusader as your unRAID file manger, you can easily copy any necessary updated files to the Flash Drive by using the cache drive in an immediate step.) 


Final Thought

I have no doubt that some of you will have ideas on how to further refine and improve this scheme.  I certainly look forward to reading about them.


Secure Writing Strategy for UnRAID.pdf

Link to comment

Another Ransomware, named "NotPetya" attack has been found out there locking down computers in many parts of the world. 




These guys are thieves who are as bad as the ones with guns but you can't see or identify them.  All you can do is try to make your data as difficult as possible for them to access. Protecting data from these guys is difficult and when you do do get some barricades up, you have also made your life more difficult by requiring you to go through extra steps to manage your data.

Link to comment

One thing I've done is utilize FIND command to make files read-only if they're over a certain size on my media shares. This leaves the files produced by media managers to be updated, such as .nfo, .xml, .txt or even the backgrounds and logos, since those are all easily replaceable. To genuinely make them secure I suppose they should also be chown'ed to a different user too.


This could replace the 'newperms' script.

Link to comment

@BRiT and @jonathanm, you both have good suggestions on strategies to protect against the encrypting Malware.  


@Brit --- You need to post up the complete details of how one would employ the method that you have suggested.  


One advantage that we unRAID users have is that the user database is too small for Hackers to bother with building tools to attack it directly.  What our problem is that most of the user base is running Windows clients and/or using SMB to connect to the shares on our servers.  Virtually all of these Malware attacks are looking for the links to servers that contain files with read/write permission so that they can use software running on the client end to the dirty work. And they want to find servers because they figure that if the files are on a server, they are very valuable to the owning organization which probably has deep pockets and they are very likely to pay up to be able to get back using those files.  Unfortunately, most of us also fit the operating profile and we can easily become a unintended target if anyone on our network becomes careless...


As I recall, there is also a Plugin which write some seed files to the server and then monitors them to see if they are being modified.  If such activity is detected, the server is locked down.  At this time, the name of that plugin completely escapes me.  Hopefully, someone will post up its name.


Link to comment

@Frank1940 Are you referring to the Ransomware Protection plugin?


To beef up my post (and to intrude into this conversation) -- my current strategy has been to limit access to shares hosted on all of my servers down to a single management system (you could potentially have this under vlan, with no internet access).


As for accessing my data -- well, I'm leaving that up to the applications that need access (I'm also limiting write access), e.g;

My movie collection can only be accessed by end-users via Plex.


If a particular piece of software needs to manipulate files, then that software is usually ran via a container (directly on the host system, so no need for a share -- side benefit here is version control).

If I need to have two servers talking, then this is done over NFS -- I lock this down to their individual IPs as well as a dedicated account for their own use. 


This is not as secure though if the server itself is compromised, let's say a Windows Server (so I simply don't have my Windows Server setup to talk over NFS).


What of ransomware targeting Linux-based systems?

Simple really: limited access. Segregated services (Docker is great for this -- same can be said about VMs).

While we lose the convenience of easily accessible shares, there should be no need to go full tinhat.

Link to comment
7 hours ago, Frank1940 said:

As I recall, there is also a Plugin which write some seed files to the server and then monitors them to see if they are being modified.  If such activity is detected, the server is locked down.  At this time, the name of that plugin completely escapes me.  Hopefully, someone will post up its name.


5 hours ago, avluis said:

@Frank1940 Are you referring to the Ransomware Protection plugin?


That is the one. 


Everyone should be thinking about this latest round of Malware attacks.  Just read the news and see how many major companies and organizations have been hit. I just read (on CNN) that the Email address for this latest one has been blocked so even if you pay the money, you can't get unlocking key.   WannaCry was the first major one of the Ramsonware variety and it  had limited success.  The next generation one (Apparently, 'they' haven't agreed on what to call it yet...) is evidently an enhanced version of WannaCry.  I have no doubt there will be a third generation out shortly which 'fixes' the 'fixes' and will have an improved distribution scheme of both the software and the payment method. 


The point I am trying to make is that everyone should be thinking about the securing of their data.  At the present time, these programs will inflect any file to which they have write access.  This means that in unRAID, you can have you Shares setup as 'Secure' or 'Private' and, if the inflected client (apparently Windows is the only OS they have targeted to date) has write access, those Shares will be encrypted!


The users of unRAID now use their servers in several different ways.  Some are using it as a Write-Once/Read-Many server for Media files or long term archiving of certain types of information.  Others are using it on a more traditional basis where the access is transactional with constant reading and writing of update information.  Each scenario will probably employ a different solution to address the problem.  


Every protection scheme will have its strong points and weaknesses.  Everyone of them will present a different set of user/usability issues and problems with doing routine data management.  I was hoping that the community could propose and develop several different approaches from which the user could select the one which will best serve his needs. 

Link to comment

Thought I would link this post that has ideas of how to protect unRAID from SMB attack via an infected Windows workstation.


Seems that @BRiT implemented a find statement similar to what I mentioned. Maybe he would share it or a generic sample of it that others could adapt. 


Putting this protection in place is relatively easy, and has little impact on our "freedom" to use our array. So long as the integrity of the Linux OS is not compromised, Linux security will stop SMB from updating files.


Most of my shares are already private, with read-only or no access to everyone but me. So I am the security vulnerability on my system. I know enough to not do dumb stuff, but don't know that I would stack ALL my data on knowing I wouldn't click a link that would compromise my own workstation.


This doesn't apply to me, but potentially a little more concerning, would be a VM configuration where access to the array is provided outside of SMB. I know that VMware Workstation (which I have used a lot) does provide some special sharing features with the host. If a Windows VM on unRAID has local-like access to something line "/mnt", it could be a real problem! Someone closer to VM features in unRAID might be able to comment if something special should be done to protect your server from a Windows VM running on your server.


Dockers, being Linux, are not at as great a risk. But I have to admit to mapping "/mnt" into the Docker to add flexibility on the occasional need to access something not on one of the folders I routinely use. I am thinking to revisit that practice, and better lock down visibility of the Docker to my array. Who knows if an author, purposefully or accidentally, would unleash some deadly code.


Finally, backups which used to exist to protect against hardware failure and user error, now need to exist for protecting from crap like this. If you've been putting off setting up backups, now is the time. And whatever you use, make sure that it is not something that will get clobbered by a security event. For example, if you have flies that are updated in the cloud as they are updated on unRAID (or even doing nightly), then an attack could easily corrupt your backup.


We have to think about it stupid crap like this because the hackers are winning. :ph34r:

Link to comment

@BRiT and @bjp999  is this link to the method that you were referring to?

If I understand this correctly, the owner would be changed to root and files being protected would be read only and this could only be changed by a Super User (in most cases)--- root.  Even doing the protection would require at this point logging in and using the command line.  Although, one could write a batch file to do the heavy lifting. 


One more issue is that when doing file maintenance, some of the files could be manipulated  through SMB (as most are currently doing) and other files could not be.  This could create a source of endless confusion to the users when operations on some files worked and the same operations on other files did not work.  


Possibly a Docker could be  written to do the entire operation through the GUI but I would imagine it would be a big project if both the protection activation portion and file management portion were rolled into a single Docker. 

Link to comment



Yes - not sure how i missed that!! Thanks @BRiT !!


A user could use the newperms script (or something similar) to unprotect media if it needs to be deleted or moved or something. And then a cron job running nightly or on whatever schedule the user wants, which can lock everything matching a certain criteria.


Another alternative would be to use a user other than "root". You could define a userid, call is Fred. Set up on Windows workstation as a logon with a strong password. And also set up in unRAID with the same password. When you assign the permissions you could use 744 and give owner of Fred. The only time the user would log on as Fred is when they want to fully manipulate the media shares including the media file (reorging, pruning, etc.). No Web browsing from Fred userid. Once complete, user would log off of Fred and go back to normal userid. This would prevent ever needing to manipulate the permissions. I can think of a bunch of other similar ways to do this.

Link to comment
2 hours ago, bjp999 said:

You could define a userid, call is Fred. Set up on Windows workstation as a logon with a strong password. And also set up in unRAID with the same password. When you assign the permissions you could use 744 and give owner of Fred.


This would probably work but you have to VERY careful in choosing that user name.  Windows (and, by extension, SMB) tends to 'remember' login credentials.  You can read here but some of the pitfalls (be sure to read the next few posts following the first one):

I know that I got bit when I picked one I made the classic mistake of thinking that frank and Frank would be two different users.  Turns out that SMB considers them to be the same user.  That turned out to be this bug/feature:

And I don't even use a Windows login to get on my Win7 Computer named but Frank is what my Windows user name is on that computer! And if you pick a unRAID user name that is the user name on another computer that happens to be on the network, the poor user of that computer will be prompted for a login whenever they try to access the server. 

Link to comment
2 hours ago, Frank1940 said:

This would probably work but you have to VERY careful in choosing that user name. 


My windows userid has spaces in it, and since Linux does not allow userids with spaces (or at least I could never figure out how to make it in my early days), i learned of a feature in the samba configuration that lets you map an incoming userid with a Linux userid. So actually, all I'd have to do it update that configuration and restart Samba, and suddenly I'd be "Fred" if I wanted to be.

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...