testdasi

I'm on 1.0 automatically. I didn't even realise I as on 1.0.

The plugin shows this line above the "Errors Found" section. Not sure if it's anything to worry about. Warning: Illegal string offset 'Port' in /usr/local/emhttp/plugins/fix.common.problems/include/tests.php on line 871

Cache Dir plugin works most of the time so I can browse folders without spinning up drives. Tested it and it works. Parity check will have to spin up all drives anyway so I don't think that's relevant. And I did not mention anything about RAID. Within the context of unRAID, if 2 people access 2 different files on the same HDD, the disk will have to spin back and forth to get the data. If 2 people access 2 files on 2 HDD then each HDD serves its own file, no seeking. That's the performance point. I think we can agree to disagree and keep it there as it really depends on each's perspective.

Fair enough but that's just perspective. My perspective is an empty drive is one that is not being used. A half-full drive is one that in the process of getting filled up. It's my asset -> I like to see my asset works Regarding the last sentence: It doesn't matter if you have all data in 1 drive or data spread out in multiple drives with unRAID. To access a single file, a drive must be spun up regardless of which scheme you are on. unRAID doesn't do stripe so the entire file is still on the same drive so only 1 drive get spun up => hence no unnecessary spinning up anyway. And if you are considering the scenario when multiple people access multiple files then it becomes a matter of performance vs electricity.

I'm from the "spread it out" school with moderation. I do try to control what material gets written to which drive, but not to the extent that chicken eggs are always in basket 1 and duck eggs are in basket 2 and 3 etc. [*]The main consideration for me is that if I have a failed drive that is somehow not recoverable by Parity (or 2+ failed drives), trying to recover 4TB manually, in my opinion, is a lot less painful (and easier to succeed) than trying to recover 8TB manually (despite the 50% probability of not having to recover anything as the failed drive is empty). [*]If the drive is completely not recoverable, losing 50% of movies and 50% of TV shows, in my opinion, is a lot less painful than losing ALL the TV shows or ALL the movies. [*]I don't have the luxury of buying drives to leave them empty. The "moderation" part is the fact that I don't strive to make sure each drive has the same amount of free space. Close enough is fine, but not exactly the same. I basically just let unRAID decides based on a "Most Free" distribution.

Be careful with that one regarding cooler. If I remember correctly, it has a narrow 2011-v3 socket, not the standard square one.

Oops, I meant to reply to parkanoid's question ("no one noticed similar behavior?"). Nothing about motherboard. Just to point out that the number of people who can assign 32GB RAM to a VM is small so that's why few people are noticing / reporting it.

Maybe the reason is very few people would assign 32GB RAM to the VM - and still able to start it. That realistically means the server has 64GB+ RAM and not that many motherboards support 64GB+ RAM to begin with.

I am very familiar with 2-pane layout back since the Norton Commander days (oh gosh, I'm old ). On Windows I use Total Commander (and love it) and unRAID console I use mc. However, since I have set up password for root, ssl in + mc to manage files has gotten a little tiring. So I decided to pick Krusader docker to do file management through GUI => since I would already login using my root password to GUI. However, it was a matter of a coin toss as I had no idea if Krusader or Dolphin is better / more similar to Total Commander. So Krusader vs Dolphin, which one is better in your opinion? I reckon for basic file operations, they are similar so it probably comes down to the advanced functionalities.

I found the problem!. Apparently it is related to OVMF BIOS. When switched to SeaBIOS, the resolution is no longer greyed out. That explains why people probably think "what a noob, just change resolution" when I raised the question. Since most people probably use SeaBIOS.

I remember seeing someone making a script to do that. However, the same person said he doesn't think it's a good idea as it creates severe fragmentation. The question is why would you want to redistribute the free space?

I think I have found the solution! I set up Syncthing on unRAID (via docker) + my workstation. Then it appears to be a simple matter to setting up the workstation side as "Master" and the unRAID side with "Staggered" versioning. Then set up Crashplan to backup the Syncthing folder on unRAID but exclude the version folder. In this way, I will always have a readily usable mirror for quick and easy restore for day-to-day usage i.e. just copy it back. Assuming I'm under attack, below are the Swiss cheese layers [*]The virus spreads very quickly on my mostly-ssd-based workstation. This should trigger a massive number of sync breaks and thus heavy activity. I should notice (a) my connection is unexpectedly continuously saturated, (b) my server HDD ligh is flashing high activity when there should be none and © a sudden massive increase in number of sync breaks. These would be the "brace for impact" warning. [*]The syncthing share is set to private and hidden. Hence, a typical ransomware would not see the network drives to encrypt. A more advance ransomware would not see any SMB share to encrypt - not that it can do anything as private = no writing from outside of the server. [*]Sync speed is limited by network speed (1Gbps). Hence, it is highly likely that the ransomware would have finished all the encryption of the workstation way before it can be fully replicated on the server. Presumably it would then pop up its "pay me or else" screen so I know for sure I'm under attack. I can then stop any potential further damage by (a) unplug the workstation and/or (b) use tablet to access the GUI and stop the Syncthing docker [*]Even if for some reasons I didn't stop the sync on time and all damages are replicated on the server (assuming it hasn't run out of space before that), the "Staggered versioning" option would mean I still have a good copy - in fact, the whole version folder is now my good copy. [*]If all above layers fail (e.g. a very advance virus that can encrypt via syncthing connection), Crashplan <-- it's almost too true in this sense . Any critic / hole spotting is highly highly appreciated. Kudos!

Question: Is there anyway to periodically mount a SMB share? I want to (automatically) mount an smb share from my workstation to my unRAID server for back up purpose. It would only mount every Friday night and unmount on Sunday night. That should be doable if there's a command line or something I guess.

Definitely stop VM autorun and double check core assignments. In terms of Windows, it should be automatic but you might be asked to reactivate.

Would this work? Share the source folder on network as SMB Set up unRAID share that is hidden and protected (i.e. not even read-only) Use Unassigned Devices to mount the SMB source folders as mnt on unRAID Use Dynamix Scheduler to run periodic rsnapshot to backup the UD mnt to the protected unRAID share Use Crashplan to back up the unRAID share to their cloud I found the limitation of my previous Crashplan-only arrangement is that I don't have a readily-usable mirror and restoring is a very long and painful process. Hence, perhaps having a local mirror + off-site backup is better in term of "quality of life" kinda thing.

In order words, Crashplan provides pretty awesome "Swiss cheese" layer against ransomware, in addition to any local NAS arrangement.

Win 10 but 7 and 8.1 have the same behaviour. Note that this is about the VNC virtual GPU. If passing through GPU then of course the resolution can be changed.

I have a similar (and inferior) arrangement to RobJ and bubbaQ but with Crashplan. I set up a back-up share which is private and not published and set Crashplan to back up there every 3 days. Basically my rationale is if I get a ransomware attack, I should be able to detect it within that period and switch off Crashplan.

Question 1: What would unRAID do if you write to a file that is already on the array? Does it write straight to the array or does it make a copy in cache first? Question 2: What if the cache is full? As far as I know, if cache is full, unRAID will write straight to array - negating any defense. Perhaps a "plug-in-able" thing to do is to have Cache-only shares linked to Array-only shares and have the plugin does the moving (since as far as I know, plugins have full access to all shares). The complication is how to see all the content in Cache + Array. Or things would be a lot easier done at LT code level. Perhaps have a "protected" flag for shares which turn cache on and disable writing if cache is full + "copy-on-write" kind of flag. The complication is with how to deal with free space and stuff. Nothing is easy. *sigh*

Awesome idea! I think right now, unRAID can be made resistant to Ransomeware attack but it would be a quite round-about way (e.g. having an isolated "high risk" VM with only some share accessible). The above would make it even better.

It only has 1 resolution. I can't increase it.

My VNC-based VM (which as I understand it uses a virtual GPU of sort) seems to be stuck at a fixed resolution i.e. tiny screen. Is there anyway to increase the resolution? I don't know maybe adding some RAM as graphic memory or something. I'm certainly not asking for 4k, but 720p would be really nice. *Edit: I did check in the VM display properties and it only has 1 resolution. I can't increase it. Hence this question.

OMG I got it to work!!!!!! And it looks like Windows actually detected it as a Bluray writer too (put a blank Bluray in and it asks if I want to use it like a USB )!!!!! I put this in the xml right before the </devices> tag: Note the index = 1 and controller = 1 amendment. <controller type='scsi' index='1' model='virtio-scsi'/> <hostdev mode='subsystem' type='scsi'> <source> <adapter name='scsi_host9'/> <address type='scsi' bus='0' target='0' unit='0'/> </source> <readonly/> <address type='drive' controller='1' bus='0' target='0' unit='0'/> </hostdev> The start the VM (which crashes but it crashes randomly due to lack of memory - oh well, running it in VMWare Workstation) and then install virtio scsi driver (which shows up as passthrough) for the 2nd no-driver scsi item - which windows just install the drivers on the virtio disk, no need to force it. Then voila! When I checked the xml again, unRAID has automatically rearranged the codes and changed it a little: <controller type='scsi' index='1' model='virtio-scsi'> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='scsi' managed='no'> <source> <adapter name='scsi_host9'/> <address bus='0' target='0' unit='0'/> </source> <readonly/> <address type='drive' controller='1' bus='0' target='0' unit='0'/> </hostdev> *there should be an emoji for celebration*

Windows says the scsi driver on the virtio disk is not designed for my drive. I tried to install it regardless and the errored scsi device went away but no drive.

I tried. It doesn't work. :'( VM starts fine (and I doubled check the hostdev section is in the xml) but nothing shows up in Windows. :'(