Squid

Under the criteria it is a valid error. However since its from bonienl it can be considered a false positive. This is why this is a warning and not an error. Only way to do things to get rid of the 6.0 plugins While bonienl may disagree my opinion is that any plugin not published in CA is potentially an issue. But this is a special circumstance . (i actually tested this routine by installing that plugin as I knew it wouldn't cause any issues) Sent from my LG-D852 using Tapatalk

Undecided about that, because right off the top of my head, cAdvisor will fail because it has 4 paths, all of which are pointed at somewhere within RAM (to grab information from the base OS). Maybe build an exception for it? but good idea though.. That, and I mount my external smb shares within /tmp so that no matter what unRaid can shutdown if UD has issues unmounting its mounts within /mnt/disks

So does that mean that there is no way to set the transcode directory to memory (i.e. /tmp)? I have been debating switching from ESXi to bare metal, and that is something I'd love to keep since it reduces wear on my SSDs... It's forced by plex not by us. We just adapted our config lonix would it be possible to reinstate this mapping? From what I can see this hasn't been forced by plex - as there is still a setting within plex to set a custom location for transcoding. However without this mapping I am no longer able to use the setting within Plex itself to use unRAID root file system which is in the RAM. I have a large quantity of RAM (as in sure some others do too) and this change has essentially crippled the transcoding feature for me unless I'm misunderstanding something, if you can still tell Plex to transcode to a custom location, just add the appropriate mapping back in yourself (something like /transcode mapped to /tmp/plex) Like any other container, you can always add as many paths as your system requires without any changes from the template authors

So that tomorrow I can fix the bug in CA's autoupdate settings (only affect this program), and hopefully add in the dated appdata backups, - Ability to only run the write checks on disks already spun up - Checks against docker applications installed where the user has changed the Container Port (more of a problem on 6.1.x as 6.2 tries to hide the setting better, but still quite possible for a user to do this), and doing it will almost guarantee the app won't work (thanks CHBMB for being a PITA ) - Ability for user scripts to check for and add to the errors / warnings / other notes section of the plugin. Any script located within /boot/config/plugins/fix.common.problems/scripts/ (must be executable) will be automatically executed by this plugin whenever it runs. A sample script (sample.php) is provided with the php helper functions I'm using, and the initialization / finialization routines that have to be done to integrate with the plugin properly. Note that sample.php is automatically skipped by the plugin when executing scripts

My bad. I assumed next day or so had already passed. You probably ought to adopt limetech's "Soon" every time you issue a forward looking statement. lol I'll try and not take offense at that My "day or two" tends to always be within a day or two or three" Actually, that was tomorrow's job for CA

That doesn't get any results. Searching for Fix Common Problems, oddly enough, works. Only way that CA doesn't show an app in available apps is if its already installed (because at that point, its no longer available). Searching displays everything installed or not.

Make a change and then apply it. Known issue as posted in 3rd post. Needs an update to CA to fix

The default is to go ahead and run the test (spin up) all disks right? Just want to make sure it's not disabled just because I didn't correct the settings after an auto update. correct. On this plug (and CA for that matter) whenever I add a setting, I always make them default to whatever I think it should be if the user doesn't go in and change it.

Thanks, that sounds perfect to me I wouldn't mind if it spun the drives up monthly or even weekly to do the full test, but right now I'm running it daily and would rather they not spin up. I suppose another option would be for me to run it less often If you schedule it to run at the same time as the parity check, then at least it'll check the writes to every drive at that point. (It only writes a random file containing "TEST" (filename checked to make sure it doesn't conflict with a file already on the drive, and then reads it back and compares -> any discrepancy triggers an error, so it won't even be a noticeable delay in the parity check speeds (ie: it will maybe slow it down by a second or two) FYI, for simplicity sake, I only offer hourly, daily, weekly, monthly tests (and disabled) I don't want to get too complicated on the scheduling just so that its all kept nice and simply for users. But you can change the actual times its run by installing Dynamix Fixed Schedules Plugin which will then allow you to adjust the time this runs at.

And the constant updates is why its an error - I know how I do software - small updates, update often rather than large updates, update rarely

With tonight's / tomorrows update I'll add it to the docker FAQ as its going to do some tests that CHBMB is bugging me to add for installed apps

braggart

Very nice! I'd like to request another feature - can we have an option to disable any checks that cause disks to spin up? I like that this can run on a regular basis, but I'd rather not spin my drives up unnecessarily. Thanks! I'll add it, but TBH I don't really see the point in skipping what is arguably the most important test there - can unRaid actually store a file within every drive. To my mind, this is no different than spinning up the disks for a monthly parity check, except that this actually does a basic test on the file system. Depending upon how another program is deciding to write the file, you may not even know that a write failed.... But, to each his own. EDIT: As a meet half way type thing, what I'll do is instead of skipping the tests that can potentially spin up a drive is only run the test on the drive is unRaid thinks its spun up if you select that option.

Now checks for blacklisted plugins installed Checks for unknown plugins installed (unknown as in not known to CA) - This will get rid of users still having S.N.A.P installed, old 6.0 only plugins, etc Further enhancements to the FTP detection, along with a comment that if it is disabled, but users are defined, then its going to wind up getting enabled when you reboot

Updated to 2016.05.09 - Fix false positive on valid file system checks when cache pool present - Enhanced detection on FTP server running - Add Notification Checks (No destination (browser, email, agents) set for warnings or alerts (If email is selected on any type of alert, check for recipient address and server address within smtp settings)

Thanks. I spent a day trying to go through a ton of diagnostics online but obviously missed that one Sent from my LG-D852 using Tapatalk

Can you give me your diagnostics. I wasn't 100% sure how it was going to respond to a cache pool Sent from my LG-D852 using Tapatalk

Check for updates as that check changed a couple times yesterday. It now checks to see if there are any entries in the authorized users. There is a big with the ftp server where if it's disabled it's going to re enable it in the next boot. But it's a warning anyways just to drive home the point about opening up the server to the internet. If there is no users listed then post back here Sent from my LG-D852 using Tapatalk http://lime-technology.com/forum/index.php?topic=48975.0 http://lime-technology.com/forum/index.php?topic=48931.msg469644#msg469644 EDIT: Now that I'm thinking about it, I can add another check to see if its actually disabled when there are valid users present. Will update it tonight.

How do I know if I've configured my server properly? You can install the Fix Common Problems plugin here: http://lime-technology.com/forum/index.php?topic=48972.0 The plugin is designed to scan and suggest solutions to many common issues and configuration mistakes. While it can't catch everything, its a start.

Just ran the new version, looks great! My personal opinion, I think that the auto-update for this plugin (Fix Common Problems) should be a Warning not an Error, but it's not a big deal. Of the autoupdates, its the only one that generates an error instead of a warning so that people turn it on to keep the thing updated with new problems / suggestions. Its a choice I made... If everyone complains I'll demote it.

But, like my edit above implies, its nothing for me to say delete 32 bit packages it finds, or delete the user list from FTP settings, or set autoupdate settings. Simple config changes. Most items however require a decision to be made, and even then it *would* be possible to come up with a script, but realistically am I going to invest a ton of time creating a script to walk through the process, getting input from the user that may only get used once? And then hoping that it actually works under all the variables present in a server... I think that the suggested fixes (and the buttons to actually take you to the correct page in the webUI) will suffice for those items.

What I'll do is switch it over to being a warning, as its not exactly a major error, and the system is still functional with it like that. Thought even more about it, and what I'm going to do is completely remove the options to have this plugin move the data around for you to/from the cache, and instead point them to dolphin / krusader / mc. I'll just leave the suggestion to fix the settings however. Makes my job a ton easier, and takes me off the hook if anything unexpected should happen during the move. Ahhhh ... You just tossed the holy grail back in the cave! Here I thought we were on a course to a tool that could find all problems, then fix them too! Like the Elysium movie medical machine. Yeah, and if I start automatically fixing issues (even if having to punch a button to do it) then I wind up taking all responsibility for everything. Its one thing for CA to backup appdata, its another thing for me to start moving somebody's family pictures off of the cache drive onto the array. Not saying that it won't happen with certain of the found problems, but lets take this one step at a time. Besides a some of the potential fixes require stopping / starting of the array to change certain settings, etc. EDIT: after 5 minutes of thought, now I'm starting to feel guilty about it and will begin adding FIX ME buttons for some of the simple fixes that don't require actual decisions to be made by the user.

There may be a false positive reported with regards to auto update of Dynamix webUI and Community Applications, and this plugin. If you have not made any changes to CA's auto update settings, a false positive will be reported for these warnings. Just go to Autoupdate Settings (Community Applications Settings) and make a change, any change and apply. From here on in those warnings will be legitimate. I have to update CA in the next day or so to fix this one time false positive

Yes, BRiT this post is reserved

Implied Cache Only shares do not have files / folders stored outside the cache drive Cache Only shares do not have files / folders stored outside the cache drive Array Only shares do not have files / folders stored on the cache drive Dynamix checking for plugin updates Dynamix checking for docker updates Community Applications Installed - Only because of its plugin auto update feature Community Applications set to auto update itself Dynamix WebUI set to auto update (via Community Applications) This plugin set to auto update itself (via Community Applications) Powerdown plugin installed Ability for the server to communicate to the outside world (ping github.com) Ability to write a file to each drive in array and cache Ability to write a file to the flash drive Ability to write a file to the docker image Similar named shares only differing by case (eg: MyShare and myshare) Default appdata storage location is set to /mnt/cache/.... (skipped 6.2-rc3+) Default appdata storage location is a cache only share Look for disabled disks Look for missing disks Look for read errors Look for file system errors Look for SSD's within the Array Check if plugins are up to date (and ignore if autoupdate settings are enabled in CA) Check for 32 bit packages in /boot/extra and /boot/packages Check for docker applications updates available Check individual docker application's /config mappings set to /mnt/user (should be /mnt/cache) (skipped 6.2-rc3+) Check for /var/log greater than 50% full Check for tmpfs greater than 75 % full Check for docker image file greater than 80% full Check for scheduled parity checks Check for shares with included and excluded disks both set Check for shares with both included and excluded disks having overlaps Check for global share settings both included and excluded disks set Check for global share settings with included and excluded disks having overlaps Check for docker containers having UD mounted volumes not being passed with slave option Check for only supported file system types (reiserFS, xfs, btrfs) on array / cache devices Check for flash drive formatted as fat32 Check for built-in FTP server running Check for destination set for Alert level notifications Check for destination set for Warning level notifications Check for email server and recipient addresses set if email notifications are selected Check for plugins installed being blacklisted Check for plugins installed not being known to Community Applications (implies incompatible) Check for ad blocker's interfering with unRaid Check for illegal characters in share names Check for docker applications not running in the network mode template author specifies Check for HPA on drives (Error on parity, other warning for all other drives) Check for illegal suffixes on cacheFloor settings Check for cache free space less than cacheFloor Check for cache floor greater than cache total space Check for permissions of 0777 on shares Check for Hack Attacks on your server Check for Moderated / Blacklisted docker applications Check for plugins incompatible for your unRaid version Check for cache only shares, but no cache drive Check for user shares named the same as a disk share Check for CPU Scaling Driver installed Check for extra parameters set via Repository section instead of Extra Parameters Section (docker Apps) Check for multiple registration key files stored on the flash drive (Excludes Trial keys) Check for Out Of Memory errors Check for MCE errors Check for Files / Folders contained within /mnt (anything other than disk1,disk2, etc or cache or disks Check for exhaustion of inotify watches Check for irq xx: nobody cared messages Check for SSD cache drive formatted as reiserFS (format does not support trim) Check for SSD cache drive, but Dynamix SSD Trim not installed Check for missing/different TemplateURL field in docker application's template Check for Marvel Based controller Check for Directory Bread's (ie: flash drive disconnected) Check for Ryzen CPU running on unRaid < 6.4 Check for minimum 2G memory installed Incompatible docker applications installed Check for CPU overheating Check for Stats plugin installed, but Preclear Not installed Mover logging enabled Zenstates not running on Ryzen CPU PHP Warnings enabled via Tips and Tweaks plugin Disk included in share setting that doesn't exist on array Check for deprecated --cpuset-cpus in extraparameters AND via CPU pinning via GUI Check for collisions on CPU isolation and Docker CPU pinning (multiple collisions only) Check for invalid docker template xml's Check for write cache disabled on drives Extended Tests: Check every file / folder for permission issues Check every file / folder for invalid characters Check for duplicated files Check for folders with same name but different case