Squid

This plugin is designed to find and offer up suggestions to a multitude of configuration errors, outright problems, etc for numerous aspects of your unRaid server. To install this plugin, just head over to the Apps tab and search for Fix Common Problems. After installation, you will see a lifesaver within Settings / User Utilities which will launch a manual scan (and give you the option to set the background scan settings) For every error or warning that this plugin finds, a suggested course of action will also be displayed. Additionally, should you seek additional help for any error / warning, the errors are all logged into your syslog so that persons helping can easily find the issue when you post your diagnostics. Scans can be scheduled to run automatically in the background (you have the option of hourly, daily, weekly, and monthly). Additionally, if the background scans find an issue they will send out a notification (depending upon your notification settings in this plugin) The current list of tested items will be maintained in the second post of this thread. Any support for problems this plugin finds, should be posted in the General v6 section of these forums. Problems relating to false positives, suggestions for more checks, why I made the decisions I did, wording mistakes in suggestions, etc. should be posted here. As usual for anything written by me, updates are frequent as new ideas pop into my head. Highly recommended to turn on auto-updates for this plugin. Most of the tests will include a link to a "More Information" post about the specific error. These are all contained within this thread: A video with a basic run through of FCP can be found here: (at about 18:25)

Done! Please visit the docker page for more info on autoupdates as well. This image will auto build from now on new release. You will no longer need to send me a request. Please feel free to do so if there are any issues, or if an image is not built within 8 hours of release. I'm confused as to how exactly I can set up autoupdates. I checked the docker page: https://hub.docker.com/r/hurricane/docker-subsonic/ but I couldn't find any information on it. I am a linux noob so I would appreciate any help. Usually I just have the update button on my Docker page in unRAID but it says Subsonic is "Up-To-Date" even though it is running 5.3 and when I click the docker it says there is a new version available and gives me the link to subsonic's home page to download it. http://lime-technology.com/forum/index.php?topic=40937.msg387553#msg387553 (although it doesn't address your issue per se, it does explain why there is no update available from the docker page)

General rule is to never change the container port and only change the host port.

It's on the to do list. Working on this http://lime-technology.com/forum/index.php?topic=40262.0 project for a bit, but still concurrently working on new features for CA

Sure. Remove the /config path mapping from the template when you edit it. BUT you do NOT want to do this. One of the greatest advantages of LT's docker implementation is that appdata is stored OUTSIDE of the docker.img. This allows you to easily manipulate it, manually change configuration options, if the docker.img becomes corrupted to reinstall Plex with all of your databases, metadata, etc and be back up and running in 30seconds (after the download of plex is completed), etc etc etc Your problem is a combination of * The amount your writing to the cache drive * The frequency of mover running * The size of your cache drive * The Global Share Settings and Cache Drive Minimum Free Space * Probably have your /config mapped to /mnt/user/... instead of /mnt/cache/...

This has nothing to do with Plex. As you've said, the cause is the cache drive filling up, leaving no space for Plex to be able to store within its appdata setting (btw, you've probably got the appdata share mapped as /mnt/user/appdata. You should have it as /mnt/cache/appdata) Changing the mounting as I suggested will probably fix the issue; Changing the minimum free space available on the cache setting will probably help the issue. But ultimately, the problem is that you're writing more data to the cache drive than its size

Be prepared! You never know when you might have to dispose of a body Enhanced: Better logging. (Syslogs will now give reasons for why shares do not appear in the available shares for backup sources) Enhanced: Optional saving (and appending) of logs to the flash drive Fixed: Suppress errors on autoupdate screen if plugin doesn't have a readme

Some of these are already handled via the notification system, (dockerimg full, cache full (I think), log full (I would hope) ), not updated to latest stable is addressed in the next rev of 6.2, but even with a notification, whats missing is a suggested action via this plg. What I've got to do is get the framework down with the upcoming release and then start adding these (and other items). My white-board is starting to fill up again...

I have way too much fun

A non-official plugin (WIP for 6.2) ... I guess its ok for you to violate your own rules Have an update for CA anyways once I manage to separate the common problems stuff out of it.

phoque Never considered that a plugin wouldn't have a readme. Curious though, which plugin is the cause.

LMAO. [emoji2] Too seal'ing funny Sent from my LG-D852 using Tapatalk

Support threads (as determined by CA / the repositories thread) are all determined by the authors themselves and when there isn't a dedicated thread for the app the authors all know that the appropriate thread is the announcement / General support thread for the repo as a whole.) Sent from my LG-D852 using Tapatalk

How do you spell that? Sounds kinda like seal in French Sent from my LG-D852 using Tapatalk

Are you going to call it "Fix Common Problems" when you release it? Just wondering what to search for. Either that or "My Server Is F*#*#d up"

It's already progressed enough that it'll be a separate plugin. As usual for me there will be a flurry of updates as things progress. Initial release (tonight or tomorrow) will have what I had in my initial screen shot along with checks for read only file systems and scheduled checks for all this in the background. The only caveat is that if I can't simulate a problem on my servers without messing them up permanently I can't include it. That being said I am perfectly willing to accept anybody's perfectly functioning server (fully loaded of course) ? Sent from my LG-D852 using Tapatalk

Because its in lsio's development repository. IE: beta / known issues / whatever. But this is the valid support thread: http://lime-technology.com/forum/index.php?topic=42092.0 for lsio's owncloud.

Anybody have any other ideas for the next module? (app related ideally) I'm sure someone is going to give me flack about flagging CA and dynamix webUI as errors if they don't autoupdate, but since they both can affect the app experience, I believe its justified.

Export your disk shares and move the appdata folders from each disk to the cache drive Once all traces are gone your appdata should appear in the drop down Sent from my LG-D852 using Tapatalk

That's exactly what it is. The appdata folder exists somewhere on the array itself (user0) Sent from my LG-D852 using Tapatalk

There is no specific place the docker image has to be. Within the system share is merely a default location. Not a required or even suggested location. My docker.ing has always been stored in the root of the cache. That option does not select to back up the image file or not. Rather it excludes it if it's in appdata. I guess I can make that clearer within the settings / manual But we both agree that it is pointless to back it up anyways Sent from my LG-D852 using Tapatalk Ah! Understood. In addition, I'm not even sure its wise to back it up since in this day and age of auto updating applications (which are all going to update when CA restarts them), the image is going to change right away, and depending upon how many auto updates the container did, what's sitting in the backup of docker.img may wind up being completely incompatible with the appdata backup and cause you a world of hurt. I have thought about pausing the containers instead of stopping them to alleviate this to a certain extent, but a pause necessitates that the rest of the system (ie: downloads if stored outside of the appdata, the media folders, etc) all have to match 100% upon a successful restore (odds being nil of this happening)

There is no specific place the docker image has to be. Within the system share is merely a default location. Not a required or even suggested location. My docker.ing has always been stored in the root of the cache. That option does not select to back up the image file or not. Rather it excludes it if it's in appdata. I guess I can make that clearer within the settings / manual But we both agree that it is pointless to back it up anyways Sent from my LG-D852 using Tapatalk

The path to the log is /var/lib/docker/unraid/community.applications-datastore/appdata.backup.log (filename might be wrong can't remember right now) Sent from my SM-T560NU using Tapatalk

Because of the extreme size of the logs (especially on initial runs) they are not saved from run to run (either on the flash drive - written at completion, or within the docker.img file) although I am considering adding an option to append the current log to the existing one on the flash at completion. The button is no effort to implement. My concern is that users are going to start an initial, hit the button, watch the progress and promptly have their browser bring the desktop to a standstill as it struggles to display a page that has 200,000 lines in it. Hence why I've got that little 2 line status display. (And everything else that the module does is logged into syslog) Beyond that, there's actually nothing to see. It's just a running list of files. Rsync will abort on an error and the error will appear in the syslog, the log on the status display, and the log on the flash. Edit: thought I would confirm something here too. The log on the flash is only updated once at the end, never during the process, as continually logging to the flash would very quickly wear it out due to the 200000 ppen, write, close processes vs a single one at the end. Sent from my SM-T560NU using Tapatalk Edit 2: because of the sizes of the logs nothing is stored in /var/log as that would require most users to have to expand their memory available to it from the default 128meg. Hence why I store the temp log in the docker.img file

http://lime-technology.com/forum/index.php?topic=40937.msg463355#msg463355 Presumably your secret key / access key / s3 path has a space and "library" contained within it Upgrading to the latest CA and turning on auto updates for whatever plugins you choose will minimize these issues