Leaderboard

We discovered a thread we found in the Debian mailing list that documents an issue with Intel processors of both the Skylake and Kaby Lake families. You can read the thread yourself for a complete debrief on the issue, but here is the synopsis, as also documented in the thread from the mailing list: Due to the nature of this issue, we are recommending all affected users do the following: Read the Debian mailing list post regarding this issue to confirm your CPU is affected. Check to see if there is a BIOS update available for your hardware. If no BIOS update is available, disable Hyperthreading in your system BIOS immediately. We are looking into providing a way to allow users to apply a microcode update as a workaround that allows you to temporarily patch out of this bug on a per-boot basis, but until that time, users with these systems need to consider it risky to continue using the Hyperthreading feature.

@limetech @eric @jonp I just wanted to make sure this didn't get lost in the pile. To summarize, unraid currently does not have log rotation features of docker enabled for the json logging driver, which can cause issues with log files getting too large and filling up the docker image. Docker has built-in log rotation / limitation feature, which can be enabled through configuring the service with the following options --log-opt max-size=10m #with k, m, or g --log-opt max-file=3 source: https://docs.docker.com/engine/admin/logging/json-file/#options I would appreciate it if this would be incorporated in the next stable Thanks

Teaser ... this is how it looks for me

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: https://www.youtube.com/watch?v=I0XCFPAsWZE 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

I have added the "shared" option, should become available in the next release.

Don't know. Mobile so can't check on my system. Maybe post in the preclear thread. I do know that there were some changes to the plugin in the last day or so Sent from my LG-D852 using Tapatalk

It's part of the preclear plugin. Not required for you to install If its causing problems uninstall preclear Sent from my LG-D852 using Tapatalk

Ok, let's got for this way. Sure, but I want it to be useful for others . I don't use subfolders in the watch directory myself. One thing to remember is that currently, the watch folder expects to have only video files. So if other files are present (like .nfo, .jpg, etc), HandBrake will fail to convert them and these files won't be removed. However, empty directories can be removed without problem.

If you have 2 step turned on, just go to https://security.google.com/settings/security/apppasswords?pli=1 to generate an app password