Leaderboard

Try running from the command line ps aux | grep ups If something is still running run e.g. killall upsmon There's some differences between the nut packages. I think I need to add some more checks to stop the previous version.

Introduction unbalanced is a plugin to transfer files/folders between disks in your array. Support Fund If you wish to do so, learn how to support the developer. Description unbalanced helps you manage space in your Unraid array, via two operating modes: Scatter Transfer data out of a disk, into one or more disks Gather Consolidate data from a user share into a single disk It's versatile and can serve multiple purposes, based on your needs. Some of the use cases are: Empty a disk, in order to change filesystems (read kizer's example) Move all seasons of a tv show into a single disk Move a specific folder from a disk to another disk Split your movies/tv shows/games folder from a disk to other disks You'll likely come up with other scenarios as you play around with it. Installation - Apps Tab (Community Application) Go to the Apps tab Click on the Plugins button (the last one) Look for unbalanced Click Install Running the plugin After installing the plugin, you can access the web UI, via the following methods: - Method 1 Go to Settings > Utilities Click on unbalanced Click on Open Web UI - Method 2<br/> Go to Plugins > Installed Plugins Click on unbalanced Click on Open Web UI - Method 3<br/> Navigate with your browser to http://Tower:7090/ (replace Tower with the address/name of your unRAID server)<br/> Check the github page for additional documentation Changelog The full changelog can be found here

Your out of space on your cache, when using different size devices the free space is incorrectly reported, your max usable space is 60GB.

New image is ready.

Looks like the system stopped logging anything on October 6th, but this did get logged on the 5th when the array started up, and probably also happened after a backup happened Oct 5 22:05:31 Storage kernel: loop: Write error at byte offset 7557210112, length 4096. Oct 5 22:05:31 Storage kernel: blk_update_request: I/O error, dev loop0, sector 14760168 Which is a write error to the docker.img file. Could have been 100% at the time of those entries into the syslog (The diagnostics currently show 24G of 60G used). Easiest course of action if this is still happening is to delete the docker.img and re-add the applications via Apps - Previous Apps A small subset of users do have problems with CA Backup when it goes to delete any old backup sets (if you're using dated backups). That issue is however out of my hands.

It's not possible to move the www folder to /config as there are no option to set it at startup. Symlinking the folder is not an option we will use. Normally you would create a subfolder in www for your images? Then we might set up a www folder in /config that copies any subfolders on startup. I'll look at it when time permits it. Too busy with work lately.

Ok Im getting the same when I upgrade from previous to latest now. I'll fix shortly Edit: It's fixed now. It will copy all the old pids to the new /var/run/nut location.

I took the GUI style efforts of Kode and Drakknar together and blended that in a new theme GRAY. Much obliged to them The new color theme has the 'header' buttons at the left side which expand when hovering over them. The top header is fixed, meaning status information stays on screen when scrolling down the page. All-in-all it gives a complete new fresh view to the GUI, hope you guys like this direction. Next, see if this can be integrated with the upcoming release of unRAID. Below some screen pictures to give you an idea.

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.