Squid

I have yet to see any container that there is ever a valid reason to change it the entry. There actually is one use case, that's when you modfiy a config to put a weburl on the end. So http://192.168.1.100:3456 becomes http://192.168.1.1:3456/application But other than that agree with you completely Then the maintainer should have done it correctly in the first place Actually, TBH I never use the webUI to get to any application. I find bookmarks to be so much easier...

The only caveat is the long standing issue with dockerMan where if the webUI entry ever gets changed, it tends not to pick up changes to it, in which case the only solution is to actually start the docker.img file over again from scratch. I have yet to see any container that there is ever a valid reason to change it the entry. IMO, the webUI entry should only show up on add/edit template if docker is in developer mode. Here's why you should never change it. #1 - The subnet your server is on changes because you grabbed a new router. Now you have to go and update all of the webUI entries if you changed [iP] #2 - For whatever reason you decide to change the host port of the applicable webUI port. Now you have to go and update the webUI entry to account for that. Leaving it alone means that any and all changes to your network will still allow you to hit the webUI. (Side Note: Fix Common Problems will pick up and issue warnings when that entry has been changed)

Not sure what you mean exactly, but if you edit the container, switch the advanced tab on, you should be able to edit which port the webui loads on. Very common misconception You should NEVER actually touch the webUI setting on the template. Its not a placeholder or anything From your example, http://[ip]:[PORT:2202]/admin, if you leave it alone, unRaid will always display the UI correctly It will parse that line to be: http://whatever_the_ip_of_the_server_is:whatever_host_port_is_mapped_to_container_port2202/admin You only run into trouble when you edit that line. (not to mention that certain versions of Dynamix webUI have an issue with not picking up changes correctly to that entry)

Has a dependency, which for something like CA I don't want. (for something like CA with its pervasiveness, dependencies are avoided at all costs since it's probably used on 90+% of unRaid systems out there) But, seems to me you could easily make a script that monitors for changes in the backup destination, then runs rclone and moves the stuff over to the remote location. And then we're also back to a symlink issue and whether or not a rclone destination supports it. And ultimately if the destination doesn't handle the symlinks, then its not going to be a proper backup (and as per a couple posts up, not all UD destinations support symlinks either)

Not a good idea to do if you have docker applications. The New Perms script can mess up the apps' config files due to change the permissions on it. Install Fix Common Problems, and there is a replacement script called Docker Safe New Permissions in the tools menu which avoids that issue

Additionally, troubleshooting mode was never really designed to run for weeks on end Sent from my LG-D852 using Tapatalk

- Support separate destination for flash drive backups - Support <BaseImage> in XML templates (by request) (for those cases where developers still want the base image to display under the full information popup, but the application feed is unable to determine the base image) Flash drive backup defaults to the same behavior as before (backed up within the appdata backup destination), but now can be set to a separate destination. In practice, what this means is that you can set it to an SMB share mounted via Unassigned Devices that's hosted on a different computer. Advantages of this is that since the backup is no longer stored on the array, you can manually restore the backup onto the new flash (after MAKE_BOOTABLE), look at config/DISK_ASSIGNMENTS.txt and set up the assignments directly. If the backup is stored on the array, you've got to first assign all of the drives before you can even get to the backup Thanks RobJ for an excellent idea. EDIT: And to drive home the point again, ALL FILES WITHIN THE BACKUP DESTINATIONS CAN BE DELETED WHEN A BACKUP RUNS. ONLY USE A SHARE / DESTINATION SPECIFICALLY FOR THE BACKUP. IF YOU DELETE YOUR ENTIRE MEDIA COLLECTION BECAUSE OF A WRONG SETTING, ITS NOT MY PROBLEM That being said, I did take some precautions. You're not allowed to set a destination of /mnt/disk1 or /mnt/cache or /mnt/user, etc for the USB backup. USB Backup (when on a separate destination) cannot be a sub folder of the appdata backup destination, etc

I haven't seen this on any of my TM shares. I have 4 currently. He's running the extended tests.

Can't hit every use case... Just ignore it if there's no problems The problem is that there are so many files, I can't see if there are any other errors (extended test). Can't you just skip shares that is exported as time machine? All the errors generated are grouped by type. So just scroll down to the end. The order of the errors displayed are: Same directory, different case Duplicate Files Permissions Illegal Characters White space starting or ending the filename So if you don't see anything after the perm problems, there's no other issues I'll look at adding other folders to exclude from perm tests Ah, did not know they where grouped up. Makes it a bit easier, except that it takes forever to load all the files to the output/results (over 10 minutes) , since there are so many (6500 files in total) Suggestion: Don't change permissions on time machine folders with new perms tool also. I've actually been dreading this would happen, although I figured it would be Crashplan that would trigger it. Gimme a day (although if its all a dire emergency, there is a workaround to force the system to ignore it)

np done current directory of execution is /boot/config/plugins/user.scripts/scripts/whateverfolderyouchose

Can't hit every use case... Just ignore it if there's no problems The problem is that there are so many files, I can't see if there are any other errors (extended test). Can't you just skip shares that is exported as time machine? All the errors generated are grouped by type. So just scroll down to the end. The order of the errors displayed are: Same directory, different case Duplicate Files Permissions Illegal Characters White space starting or ending the filename So if you don't see anything after the perm problems, there's no other issues I'll look at adding other folders to exclude from perm tests

Can't hit every use case... Just ignore it if there's no problems

Diskspeed script creates an HTML file which you then have to load in a browser.

Since April 2015. (First release of Community Repositories)

Thanks for the responses. Hope to migrate to another owncloud docker or nextcloud. gfjardim deserves a lot of credit for his efforts no doubt about it. Since his last post in April not one single clue that this docker will / will not be supported any longer. Let's give the user a little more respect. My point was that owncloud haven't even updated their own official docker container to 9.0.3 yet Sorry if you took offence (although tbh as you noted, gfjardim does disappear from the forums / support for long periods at at time)

Looked a bit closer. Those errors are from the repositories. Since you're using CA, there is zero reason to use repositories. Go to Docker - Docker Repositories and get rid of everything in there.

If I was going to take a guess, either unRaid lost track of your flash drive, or your flash is corrupted. Its not CA Diagnostics should tell the story

The official owncloud docker app is available on CA (and has been forever) (Bungy's repository) which pulls 9.02 (as of today). EDIT: According the the owncloud website 9.03 was released yesterday, and owncloud hasn't even updated their docker container yet. If you choose to stick with owncloud and not switch, then you really should cut some gfjardim some slack.

- Downloadable logs

Each share has its own settings for whether or not to use the cache disk. The docker appdata share should be set to only use the cache disk (as if it gets moved onto the array at night it can mess up the applications)

Thanks... never noticed. Fixed on next update or uninstall / reinstall

Sure, with a single cache drive its still possible to lose data because its a single point of failure) However, if you don't run VM's off of the cache drive, I'm not sure the redundancy of having a cache pool is worth the investment (unless the data in question is mission critical). IE: if all you're using the cache drive for is for docker appdata, and a cache for the media downloads that your apps make, I don't think of it as a big deal in the event of a failure. - Appdata can be backed up periodically (ie: daily) via CA - In the event of a failure, replace the cache drive, restore the backup, recreate docker.img, and the apps are going to begin d/l the media again that also wound up getting lost.

Almost sounds like your cache drive (ie: your appdata share) is mounted to be read-only. Post the logs from Couch Potato, and additionally your diagnostics

All warnings are just that: warnings. They don't necessarily mean that you're going to have problems (but the extended test on the latest version is more comprehensive and a better judge of if problems will happen) Lately I've been bouncing back and forth between plg updates, and FCP is next on the list, and the permissions check is what I need to address. Nonstandard permission by and them self aren't an issue, but is also dependant upon the ownership of the share, and I need to account for that. The dockersafe new permissions will set everything to the "standard" permissions (except for the appdata folder that it finds)

Rub your nose in it? Nah, we're more mature than that... ok... maybe I'm not more mature than that, but I'm positive sure reasonably confident will assume there has to be at least one person who isn't laughing