itimpi

When I startup/reboot unRAID I am getting the following error message in the syslog shellinaboxd: Failed to find any available port If I go to Settings->Command Line I have to then disable/enable the ShellInABox server before I can use the option. I have not changed any settings from the default. Once I have done that it appears to work fine without further error messages. Any thoughts? Do you want the full diagnostics?

192.168.122.1 __MSBROWSE__<01> DJW-UNRAID • 192.168.122.1

On my unRAID server the Local Master is shown as 192.168.122.1. The problem is that this address is not visible from other PC's on the LAN, so they will not realise that the unRAID server wants to be the Local master and will choose their own master. That can result in the not seeing the unRAID server properly. The 192.168.122.1 address is that associated with virbr0. I do not think that unRAID should be letting any of the NAT style bridges act as the Local Master? Should this be raised as defect?

Especially since the licensing change that counts all connected devices instead of just array devices. I expected them to manage the devices since they are charged against the license limit. Wow, is that true? Yes - for all licenses except Pro even devices not managed by unRAID are counted against the license limits. However since the limits for each license have been significantly increased in practise this has little impact.

This is often caused by a particular docker being configured in such a way that temporary files are being created inside the container when ideally they should be external. If this is the issue, you would need to narrow down which container to fix the issue.

The drives do not have to be the same size. The cache uses a variant of RAID-1 when there is multiple drives so with multiple drives the available space is determined by the smallest amount that means data can be held on at least 2 drives. You can also mount drives outside the array. The Unassigned Devices plugin can help with managing this. Note that if you have any license other than Pro all devices attached to the PC count against the license limits regardless of whether they are being used by unRAID.

I recently replaced a 6TB WD Red that I had been using for parity with one of the Seagate 8TB drives. I found that on my system at least I got slightly better performance with the 8TB drive as parity than I had been getting using a 6TB WD Red. Since these 8TB drives are (currently at least) slightly cheaper than the 6TB Reds any new drives I buy will be these 8TB drives rather than the 6TB Reds I had previously been buying.

The SASLP-MV8 controller is widely used on unRAID without issues. I have several of them and they work fine. I have found cases where a bad drive takes down the whole controller but that does not seem to be specific to the SASLP-MV8. The other time I have had problems was when I had not seated the SASLP-MV8 perfectly into the PCIe slot (because the backplate was slightly bent). I found that this was very hard to diagnose as the everything seemed to work fine until one put the system under heavy load, but since corrected there have been no issues with that controller.

Found a potential issue with bunker in that if it is running it can stop the array from being stopped. I assume that this is probably fixable by adding a periodic check somewhere to see if the array is being stopped and if so aborting bunker from checking any more files. If anyone knows what can be checked to see if unRAID is trying to stop the array I can probably work out the patch to bunker to make use of the information.

New version 1.14 is made available in the OT together with your additional scripts (these are all located in the zip file). Thanks for your contributions, much appreciated. Glad you were happy with the suggested changes. I would have preferred to PM something like this, but it appears that the forum does not allow attachments with PM's.

Here are yet more improvements to the syslog output for you to check out. I noticed the output was not being tagged as from 'bunker' if they were warning or error messages so have rectified that. I also move some tests into the writer() and Logger() functions that simplified the rest of the code a bit. I have also included copies of my current bunker-verify.sh and bunker-update.sh scripts that I currently run as cron jobs. Not sure if these will be of interest to others? bunker_v1.14.zip

Strange as Cache-Dirs does not actually change anything on the disks. All it does is periodic listings of files/folders to try and keep the relevant directory entries in RAM for performance reasons to improve the experience of browsing the file system. Cannot see off-hand how that would affect Plex.

Files being owned by 'nobody' should not stop them being deleted over the network. You should not need to regularly run the New Permissions tool if the system is correctly set up and configured. Perhaps when you next encounter this problem you can do a command of the form ls -l path-to-files from a console/telnet session and post the results so we can see what the permissions actually are at that point. You also need to get to the root cause of the issue. What is actually creating these files? That is what is likely to need fixing.

I personally actually think perl and python which are large packages should probably not be in the nerd pack which should be kept slim. Perhaps they should each be in a pack of their own?

I think ANY problem with the preclear is an issue. The results of the preclear run should be stored on the flash drive in the preclear_reports folder.

OK - here is the bunker script with the changes I mentioned. I also changed the version number to 1.13 on the assumption that was likely to be what was wanted. Yeah, make your changes and send an update to me. I will make a new version available in the OT. bunker.zip

For your net revision (if any) of bunker I would suggest a small tweak: Adding '--tag bunker' as a parameter to logger in your Logger function Removing the prefix 'bunker -' from the text of the message in all the calls to Logger It makes the syslog output look a little tidier and is more consistent with the style of other messages written to the syslog. If you would prefer a patch to save you work I can produce one for you.

Put your ideas forward, there are definitely more ways to automate the script. Mine certainly is not the only (or best) way. OK - I should have something to look at shortly. When you make a GUI then a good approach is to let the plugin download the zip file from the forum, I have done something similar for cache_dirs. This ensures that people installing the plugin get the latest version of bunker. That was what I was thinking of doing - just checking you were happy before I made any assumptions. There is no exit codes to indicate different failures, results are stored in a log file. Btw bunker is a shell script not a true binary. I had not realised it was a script. I guess that rather than simply suggesting changes I can try providing a patch for you to approve and/or validate. If I still think some exit codes might be useful I at least know how to add such things to a script

Good point. I will have to bear that in mind. At least my assumption is correct and I was not misreading things. Fair enough. I must admit I had only tested it on disks which were primarily video type media files and the total was less than about 10,000 files. Not tried it yet on my music files or software archives where the number would be much higher. I have been taking your scripts and reworking them so that I have a bunker-update.sh script based on your daily one that runs checking for recent changes and handles the adding/updating of the checksums. I am assuming initially that it is run hourly and using -D 6h so that there is quite a bit of overlap but the execution time should still be quite short.[br][br]I was thinking of also having a parameter option to put no time limit on it. The idea is that this one could be used for an initial creation of checksums. It is likely to run for days/weeks on my system with 20 drives to work on but it will take the tedium out of typing commands. a bunker-verify.sh script based on your monthly one that handles verification. The idea is that it is run daily and verifies one disk per day and the disk selected varies each day. This should give a more frequent check than your monthly script as each disk is checked once per month, while still ensuring that there is not too much load on the system. To avoid the most likely times for parity checks I am avoiding the first and last days of the months as candidates for checking the disks. Can you see any reason why this is not a good approach to handling the verification? I am more than happy to pass these scripts back for others to use if they are likely to prove useful. Any thoughts on this, and also am I perhaps likely to be duplicating work you are already planning? Assuming the above scripts work out OK, then I was thinking of trying my hand at a plugin to put a GUI front-end on the installation, configuring and scheduling execution of bunker. If I get that far (which is not at all guaranteed ) do you have any objections about me including the bunker binary as a download in such a plugin or should users just be prompted to install it manually? BTW: Are there any useful exit codes from the bunker binary that it might be worth checking for? I was thinking in particular of codes indicating error conditions.

A small improvement to your daily script is to include the lines at the top of the for loop for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ; do # Only operate on disks that are actually present in this unRAID system if [ -e /mnt/disk$i ] ; then as that removes any need to alter the script to specify the exact number of disks in the system. Also I was wondering if the -D 1 line should specify a larger value in case a parity check was running the last time this script was run and it therefore exited without doing anything? It seems to me that the current version of the script would omit calculating the checksum for that missed day. In fact on a disk where all the checksums are already added, that parameter does not seem to speed things up much at all so maybe it is mainly useful when first building up the checksums?

I created version 1.12 which has a new option -L, this allows bunker to create log entries only when changes are present. See OT for download. Thanks for adding that option. I will test it out today.

Could I request and enhancement to the -l option (perhaps -L) where only lines with non-zero values are written to the log. At the moment with 20 disks in the system I get a lot of entries reporting 0 changes. It would be easier to pick out significant entries if only the non-zero entries were logged.

Just tried that link - and it takes me to a page (on Mediafire) for downloading the ZIP file containing the files needed.

Looks like there could be a buglet in displaying the initial estimated time to complete? I am creating the initial checksums for a 6TB disk, and I started by getting the following displayed: Currently processing file 2 of 3539. Completed: 0.1% [ETA: 13695459:24:16] which is rather an excessive time This later corrected itself to: Currently processing file 10 of 3539. Completed: 0.3% [ETA: 29:03:57]

Please feel free to format and/or reuse as required. Regarding bullet points, I am not against them per-say but think they should be used to make points and to separate steps. I try to avoid adding them to paragraphs that do not need them so that they stand out a bit more when used for organisation purposes.