itimpi

You can add another row or column to put them in and "turn off" the unused slots so they aren't displayed. Could not see how to "turn off" the unused slots if I added another row. Probably something I am missing. Another question - I am currently using 2x4GB drives in a RAID-O array to give me a 8GB parity disk. Any recommended way to handle this case where one logical drive at the unRAID level actually occupies 2 slots in the cage layout? Finally I notice that my 4TB WD Green drives and my 6TB WD Red drives display blank in the Manufacturers column - is there anything I can do to get the manufacturer displayed? Is there any information you might need to work out why these might not be displayed?

I have an array with 20x3.5" drives organised in a 5x4 matrix of hot swap bays which are accessible from outside the server. I also have two 2.5" SSD's which are mounted separately inside the server. I would love it if there was a way to indicate these last two drives separately from the main bank (rather like the Flash drive is).

Hit the Log button for the Dropbox container. In the log is given the URL that needs to be run to authenticate the Dropbox container against the account it has been set up for. You can copy paste that URL and run it on a different system - it does not need to be run from the unRAID server (which does not have a browser installed). Note that this is mentioned in the configuration instructions for the Dropbox container shown when you select the Edit option for the container.

As far as I know this message does not stop the diagnostics zip file being created. Have you tried looking in the 'logs' folder on the flash drive to see if it is there? One change I would recommend that is made to the diagnostics script for a future unRAID release is an information message saying that the zip file has been created and giving its exact name (including location). This will help those who run it via the command line.

As far as I know you should just be able to run any Docker container as long as you are prepared to start/stop/configure it from the command line. That is part of the 'magic' of docker. Making a Docker container unRAID friendly involves developing the XML template to go with it so that it can be managed via the GUI. The other thing that most Docker containers that specifically target unRAID share is common base images which keeps the size of the docker image file down.

That feature does not exist as far as I know. Most people tend to have multiple shares so it is not an issue. Having said that I am surprised that you said cache_dirs cannot cache all the files with 8GB of RAM fitted. Are you running other RAM hungry applications?

The only thing that stops you going back is using one of the new options for file systems (BTRFS or XFS) as v5 does not recognise those. There is no hard-and-fast rule. It is just a case of working out how much data you expect to put onto it. It is quite likely that the size you mention would be fine unless you load a lot of data onto via apps in Docker containers or VM's. In most case it is just a case of configuring the relevant Docker containers to point to where your existing configuration settings and data are stored.

The same file can be created using the 'diagnostics' command from a console/telnet session. It will be placed in the 'logs' folder on the flash drive. There is no syntax. Simply type that command press Enter and then when it completes look in the 'logs' folder on the flash drive for the zip file that has been created. I guess my search is broken because I have looked for the "diagnostics" command from the CLI, and I could not find the right syntax. Does anyone have this in case this happens to me again? I would like to be able to dump that diagnostics file onto my flash drive before I power down if this happens again.

The same file can be created using the 'diagnostics' command from a console/telnet session. It will be placed in the 'logs' folder on the flash drive.

Glad to hear that our rambling did not (quite) make you miss this issue. Now to convince Limetech that it is worth including in the mainline release. It might be worth suggesting as a change for a beta release followed by a poll to get feedback? I thought it was a no brainer but at the moment I gather Limetech do not think so.

OK. I think I missed one of the copying stages you planned to do

Up to here is what I would expect. Not sure what I understand what you are trying to achieve here? What you have specified should work but it will end up with all the files that were originally on disk2 now on disk1 and vice versa. I would have expected you to be copying the contents of disk1/t back to the reformatted disk2 to get back the files that were originally there? Is that what you are trying to achieve or have I missed something?

I saw that. I was wondering how many of those commenting had actually tried out your change? It seemed a very simple and intuitive change but maybe that is just my perspective. That is not to say that a bigger discussion is not merited. Since you know what change you made in this plugin I was wondering if you could point out the detail? I was thinking of looking at whether a similar change could be manually 'patched' into the generic support libraries so I could see what it felt like on other screens. That is assuming it could be done at the generic level and will not need change in every screen?

Many people have cache only shares which keep the icon yellow constantly. I would be ok with changing the behaviour to ignore cache only shares, and only show yellow if there were unmoved files that should be moved with the next mover action. That would make a lot of sense.

I am not sure I agree here. What if for instance mover stops working correctly. You would then get no indication that anything is wrong. I am quite happy with the described behaviour as if I have added files it is a reminder that mover needs to be run (possibly manually if the files are important) to get to a protected state. I would also in normal behaviour get used to seeing the icon start the day of green as all files have been moved to protected storage and then turn yellow during the day as new files are added that are not protected. If it started the day of yellow then I know I should check things out. What IS important to me is that errors are indicated in red as they indicate that I really MUST take some action. I guess the proof is going to be as users get used to the system and provide feedback as to whether it is found to be confusing or not.

I've started the transition to adding a 'clean' install, which unfortunately means the page is a little MORE confusing at the moment, since it's only a partial transition yet. I started with the idea of 2 types of upgrades, "a 'clean' install" and "an 'upgrade' install". I'm closer to understanding the issues now, and it really looks like it may be best for anyone coming from ANY version prior to v5.0 to skip v4.7 and v5.0, and do a 'clean' install. I'm open to better terminology... I agree that a 'fast route' to v6 without intermediate steps seems a good idea if coming from a pre-v5 release. There have been a number of people asking about this in the forum so covering it makes sense. It is also not a bad route for those coming from v5 who should revisit decisions they made some time ago. Will keep trying to think of 'better' terminology. I was rather surprised by this, by your teacher! It goes against everything I have ever learned about them, or ever seen, so I'm going to have to research it, perhaps I've been wrong all my life! Or perhaps it's a regional thing... I checked on Wikipedia and that says that both comma and semi-colon are valid separators for list items in a sentence. It mentions semi-colon as being of particular use when the list items themselves contain commas, or the sentence contains commas that are not being used as list separators. Sounds very much like something that could vary by region or even personal preference. I checked a company document I had aimed at technical writers writing software manuals and that mentioned semicolons as the preferred practise as it was never ambiguous (but also said that was not a rigid guideline but just a suggestion and the author should do what 'felt right'). Can you rewrite this sentence? It's not clear if you are referring to helping those with customizations, or helping those who help those with customizations, or maybe it's both! But also, do you think this sentence is necessary? Even I could not make sense of it and I wrote it I have chopped out some of the redundancy so now it should make sense. I would suggest that anywhere you notice a sentence getting confused like that one you just chop out the redundant words as the result is certain to be easier to follow. The reason I thought a little preamble is a good idea is that many (most?) of the users that are likely to use this guide are those who have not kept up with what has been happening during the v6 development cycle, and may well not have touched the setup of their system for years. A few (short!) positioning paragraphs might help convince them the guide is relevant to them and worth spending time on. I do, however, get your point about concentrating on the basics and trying to keep the eye focussed on what is the goal. One idea might be to use multiple pages to cover all the material. This would not shorten the overall amount of text but might make it easier to navigate and follow the basic process. As an example one could put the sections on customising settings and installing plugins onto their own page and the top level page just refer to these as steps to be carried out. It would keep the top level process cleaner while still providing a repository of useful information about the finer detail. Good idea. I originally added the license key stuff thinking about the users coming from the 'free' v5 license who might not have understood the implications of the change in the licensing model and would find they could not start their array because they infringed the 'attached devices' limit. Perhaps that special case should just be emphasised and the detail should just be handled by giving the link to the Limetech provided pages on the main web site? Other thoughts: I was wondering if the Research and Decision Making section material should be also be positioned under the Important Considerations category (and possible slightly reworked with that change in focus in mind). It feels a bit clumsy where it is at the moment and detracts from the flow of the upgrade process. What do you think? Another possibility is putting it under the '''Other Topics''' part of the document if you want to keep the main process flow less cluttered. Also in the Important Considerations section I think it would be worth formatting it so the each bullet point starts with a bold 'title' that summarises that point and then explanatory text. That way someone skimming that section might at least get a feel for the areas that are covered without reading all the text. Do you want me to make the (small) adjustments to conform to that style? The '''VM Images''' section feels 'sparse' at the moment. Perhaps as well as guiding the user to the relevant part of the forum it should also provide links to some the excellent articles and videos that JonP has been producing covering this topic area? The JonP articles may well now provide a better starting point than diving into the forum KVM area? The '''Go File Items''' feels a bit out-of-place where it is. Maybe it should be much earlier in the document? Maybe as high as just before the '''Meet the New GUI'' section?

I agree with this and maybe some variant of your wording needs to be stated. However it is difficult to clearly explain to the naïve user in how the sort of isolation provided by dockers and VM's helps maintain system stability if they have not got a background of trying to troubleshoot 'dependency hell' type issues. Another point along the same lines is that dockers or VMs that are created now in v6 can be expected to run without change on future releases of the base unRAID OS (e.g. 6.1) whereas this is much less likely to be the same for plugins - particularly complex applications that may have many dependencies on particular versions of other system components. The big issue is that Dockers are a brand new concept to most users and many would rather not put any effort into understanding them. The new Docker Manager and VM Manager are huge steps along the route of users not having to understand the details. Good guides on how to use them for common Use Cases may well help as then there are step-by-step procedures that can be used without any need to understand the underlying detail.

I started off intending to make minor changes and got a bit carried away I am afraid. I was not trying to remove anything but expand on some sections which seemed brief and add additional material in some areas. In particular I was trying to look at it from the perspective of a naïve user who has little familiarity with the insides of unRAID without removing information that is of use to the more experienced user. That does not mean that I did not miss some of the intent of the original wording. I suspect that when one person tweaks it and the next one tweaks it again then the result is almost always better than the original. One thing I know I did in a number of places was remove bullet points where I felt that the text did not need them as you seem to have bullet pointed nearly every paragraph. To me that makes it easier to read, and also makes the bullet points more prominent. It is always hard to get a good balance between brevity and completeness. One mantra I try to keep in mind when writing user documentation is to try and make the key points clearly identified and stand out from the additional details that is often needed to expand on the points. I initially thought I was just going to make a list of points for discussion, but then made some small 'obvious' changes and got a bit carried away. I was trying to think of points that have been raised repeatedly in the forum and see if some of them could be headed off by providing a bit more information. I thought that it did not read well, and that the next sentence on the same point clarified who should consider using the No Format section. I am strongly in favour of users not going down the No Format section. In fact I wonder if the No Format section should have something like: Expert Users Only added at the top to make it even clearer that the No Format route should be taken as rarely as possible. maybe the word 'Alternate' should not be part of the heading, although I understand why it is there. In fact I wonder if it should be positioned somewhere else in the document as placing it before the recommended route seems to give it undue prominence. Perhaps it would be better placed AFTER the section on copying Configuration files? I was not think of the Make Bootable being inside Copy File - just another step I was think of getting the Flash drive into a state where the Flash drive could be used. For me putting it early has always seemed a good thing. One reason for putting it that early is at that point you could stop and boot off the Flash drive to check things out if necessary. Another reason is that one variant of the recommended route that is not covered at the moment (and I am not sure of the best way to include it) that I think would be worth considering including is a variant of the "Clean Install" process where you do not copy any configuration files back and simply reassign the drives to keep the data back but then set up all the remaining settings manually. There would need to be some explanation of the fact that unRAID recognises previously used drives and keeps their existing content. This would mean that at least one would be seeing all the current defaults and consciously changing them rather than blindly accepting decisions you made a long time ago. This route would definitely want the user to take extensive screens shots of the current settings for reference purposes. If going down this route you would be ready to go by the time this point in the steps had been reached. There could be a short section describing this and how to prepare for it before the step on Copying Configuration files. It also occurred to me that the 'clean' install method might be relevant to those who want to jump straight from a release prior to the v5 series although that would need some validation. EDIT: Another point that has just occurred to me. I wonder if it is worth pointing out that this could be a good time to boot unRAID 6 just to check that all your hardware seems to be recognised by v6? This might not be the case if some users are coming from very old hardware? It seemed to work fine when I tried it. However as I only have 2 keys I may just have been lucky. I booted up the stock unRAID v5 GUI to remiond myself what it looks like and I think that the v6 one looks very different. That is however a subjective opinion. Not hung up on whether it is very different. I think there are so many changes to the layout and new pages and settings that it is very different. I have a couple of friends who are thinking not yet unRAID users but are thinking about it. They looked at the v5 GUI and were underwhelmed, but think that the v6 one is far better. I agree to some extent, but if changing the layout improves usability then it is an improvement from a new users perspective even if the base functionality is unchanged I do not think I have ever been told I have that perspective I was always taught that semi-colons is the correct way to separate what are effectively a list of items in a single sentence. Commas can be used in the right context for this purpose, but since commas are far more general purpose I do not think that using semicolons is ever wrong. This was one I just changed on auto-pilot because it is what my grammar teacher always drummed into me as good practice. However I guess this could be something for which different parts of the world have different preferences? I cannot agree more strongly with this point. I always find the 'Done' button is easily accidentally pressed and changes lost. One possible recommendation for change while still keeping the current style would be that it popped up a warning about 'unsaved changes' and asked if you wanted to lose the changes. Another possibility would be that when the Apply button was enabled the Done button was changed to read Cancel. This would probably not be difficult to do and would make the consequence of pressing it more obvious. Agree. I think I had in mind that using them for apps that could easily reside in a docker should probably be deprecated but I did not want to denigrate the effort that has been put into making v6 equivalents to v5 plugins. Having said that I am not sure how well maintained application oriented plugins will be going forward - but that is just my view. I agree that this is the case for many of the commonest plugins. Maybe adding the word Virtualization was wrong, but it seemed to me that most of that section was about when you should use Docker or a VM so that understanding those two concepts was key to whether they should be used instead of a plugin. I agree entirely - in fact I use the plugins I mentioned. Maybe instead of 'Virtualization' something like 'Adding additional functionality' should be used instead? I feel that although the section has all the key material in it that it does not read particularly clearly and could probably do with some rework to add clarity. OK maybe I messed that up. One thing I have found useful in such cases is enclosing the second and subsequent paragraphs in paragraph tags as it keeps the indents and spaces the paragraphs out sensibly. Maybe you are right. However I felt that these plugins were the ones that overlapped significantly into the application space where dockers live whereas the earlier ones listed do not. I think that many people have so little experience of knowledge of the Docker technology that repeating areas where they should be looking at the docker alternatives still bears repetition. Perhaps as an alternative this means a bit more should be said about docker in the Docker section of the document by giving as examples a list of the commoner applications that are available as dockers. Do not worry - I am unlikely to make anything like as widespread set of changes again - I did say I had gone a bit overboard once I got started.

The keys you already have are valid for any version of unRAID so no cost for re-using them with v6 If you want additional keys then the price is as on the web site.

That is suspicious. There is no way that stopping and starting the array without a reboot should ever trigger a parity rebuild. This suggests that there might be some sort of corruption on the USB drive that is causing it to be treated as read-only so that changes in the GUI do not get saved. It might be worth putting the USB stick into a Windows PC to see if Windows can detect (and fix) any such errors. Not quite sure what you are trying to say here? There is always the 'New Config' option under the Tools menu that sets you back to the position of having no drives assigned. From there you can assign the drives, and if you have assigned a parity drive then on starting the array parity will be built from the drives assigned. Thanks.

Not sure if that is possible in the current GUI. However a simple work-around would be to stop the array; change it some other format; start the array and elect to format it; stop the array and change it back to XFS; start the array and format it again.

If you have allowed the User Shares to use all disks, then you do not have to do anything else. If you have restricted and shares to only use specific disks, then afterwards you should change the share settings to match your new layout.

If you do that you should have a running array! Things you might then want to check for: If User Shares are enabled then every top level folder on the disks will have a corresponding User share automatically created with default settings. You might want to check the default settings are what you want. Any user settings will need setting up again if you need anything other than unrestricted access to shares. You need to decide if you are going to switch on various optional items under Settings such as Docker, VM and UPS support.

It may also be the linux NTFS driver which has a history of being slow. You want to make sure that you have the latest ntfs-3g driver loaded which I do not think is part of base unRAID. I do this via the Unassigned Devices plugin - but there are other ways of doing this.

No - reads from full reiserfs disks should not be affected by the performance degradation that affects writes on full disks. Is the USB drive that you are trying to write to connected via USB2 or USB3? It may well be that end that is actually turning out to be the limiting factor. Also, what format is that drive?