dlandon

I've sent a PM to gfjardim to see if he can give me a hand with the Azure and Gray style sheets.

Yes it is. These are the style sheets I asked you to look at. I'm not a style sheet guy. I just copied the white css to azure, and black css to gray. Color adjustments are needed.

The 'Used' and 'Free' indicators are very lightly shaded and if you look closely you'll see the shading is wide and fits. The issue is that the graphic indicator is left justified and it looks mis-aligned. The field should probably be shaded differently to be more discernible. If you look at the 'Main' screen, you'll see the same issue with the 'Used' and 'Free' indicators on the drives. This is built into Dynamix and is not under my control.

I don't know if you had a filter set up to remove older events, but I set up a 30 day filter so the events don't grow to an unreasonable amount. The default filter setting of 50% of the disk space used is not appropriate in the unRAID environment. This is the filter I use: This limits the events to 30 days worth.

So you are saying that the chmod and chown permissions settings took 20 minutes to apply when the docker started? If this is true, then my change to apply the permissions when the docker is started is not a good idea. EDIT: The permissions applied by the docker are:

The data/ permissions are corrected every time the docker is started in the latest docker build.

The permissions are set when the Docker initially creates the data/ folder and are never changed. If you copied the folder and the permissions were changed, they would not be corrected by the Docker. I will take a look at the first run script and see if it might be appropriate to always set the permissions when the Docker is started up and not just when the data/ folder is created. That would prevent incorrect permissions from being left on the data/ folder.

I've changed my docker templates to be more standard - i.e. default mapping is /mnt/user/... I guess I missed the memo from jonp.

The original template I used for the ownClooud docker I put together was cloned from the linuxserver beta docker they created over a year ago. The original appdata mappings were: Data Path: /mnt/user/appdata/owncloud/data AppData Config Path: /mnt/user/appdata/owncloud/config Because of some changes in DockerMan since the original template was created, DockerMan changes the config path when you install the Docker from CA to: AppData Config Path: /mnt/user/appdata/ownCloud When setting up ownCloud from CA the appdata mappings will then become: Data Path: /mnt/user/appdata/owncloud/data AppData Config Path: /mnt/user/appdata/ownCloud This results in two folders being created in appdata: appdata/owncloud/data <== data folder appdata/ownCloud/ <== config folder While this works for the Docker, Windows ignores file and folder case and sees these folders as one. This is a bit messy. To clean this up, I recommend that you stop the Docker and use a tool like MC or use the command line mv to move the appdata/owncloud/data to appdata/ownCloud/data and remove the empty owncloud folder. This will clean up the two folders situation and if you go back to the default template, the mappings will be correct. You will need to change the data folder to /mnt/user/appdata/ownCloud/data in your template, or go to CA and re-install ownCloud with the default template.

Is the documented somewhere that I missed? I cloned the ownCloud docker from linuxserver and their original template specified: Data Path: /mnt/cache/appdata/owncloud/data AppData Config Path: /mnt/cache/appdata/owncloud/config DockerMan is changing the AppData Confg Path to /mnt/cache/appdata/ownCloud. Now there are two folders in appdata: appdata/owncloud appdata/ownCloud This is very problematic in Windows because Windows ignores the case and thinks they are both the same folder. It is also a messy appdata mapping. I have changed the template to use ownCloud for the data, and DockerMan will do what it insists on the appdata path so at least the mappings a cleaner. I understand why LT did this but I'm not sure it didn't create more problems than it solved. Maybe it would be better to have a template macro to specify the default appdata folder that the docker author could use to keep DockerMan from making assumptions the author doesn't want. For Example: Data Path: %APPDATA_PATH%/ownCloud/data AppData Config Path: %APPDATA_PATH%/ownCloud/config I'm not an xml guy, so I don't know if my %...% syntax would work, but you get the idea. This would make the mapping clean and would not meddle with an author's intended mapping. Some of us do know what we are doing. For the docker templates that don't conform, go ahead and make the changes.

It's difficult to write a generic sample script to cover all cases. It depends on your specific needs. The UD script gives you the mount point in the variable $MOUNTPOINT. That would be the source (IUSB disk) and the destination is dependent on where you want the contents stored. Something like this: rsync -a -v --delete $MOUNTPOINT/ /mnt/user/(where you want the stuff stored) 2>&1 >> $LOGFILE Be sure to test carefully before going live. Be careful with this command because it will delete files in the destination that are not on the USB. If you want the file copy to be additive (i.e. nothing is removed from the destination), remove the '--delete'.

I updated the template on my repository to fix a formatting issue and that is being picked up by CA properly. I believe there is something in my template that CA is seeing different than what I intended. It is changing the appdata mapping form '/mnt/cache/appdata/owncloud/config' to 'mnt/cache/appdata/ownCloud'. Squid, how do I go about tracking this down? When I test the template in docker, it shows exactly as I intended.

What I'm trying to say is that is what I get in the default template but it should be '/mnt/cache/appdata/config/owncloud/config'. That is in the default template that is on the repository, not '/mnt/cache/appdata/ownCloud'. It will work, it's just not the way I intended the mapping to go. My concern is that the proper template is being used.

So it defaulted to the '/appdata/cache/owncloud/config' when you did the default from CA? I didn't edit it. In fact 'My-ownCloud' doesn't have that mapping so I couldn't edit it.

I think CA is coming up with the wrong template for my ownCloud docker. The default Appdata Config in the CA template is '/appdata/cache/ownCloud'. This was in a template I updated weeks ago. In the template on my repository it is '/appdata/cache/owncloud/config'. What is causing CA to get the wrong template? Or is it an error in my template?

No change.

That's weird. I'm at 1280.

Can the icons on the right be lined up horizontally?

If you just did an update of the docker, your settings will be used and not changed.

That should work. Look at the docker log for Zoneminder and see if there is anything about the database update. If you don't see a database update entry, restart the docker and watch the log.

Updating the docker is all you have to do. What did you upgrade from? Another Zoneminder docker?

Using 6.4-rc2 Azure theme. I can't enter a value in "Delay in days before updating applications:".

Here we go with the "My dog is bigger than your dog!".

Updated UD for 6.4 Azure and Gray themes.

You'll also notice the spinny thing throws up a black background. I'll do what I can to get functionality back. bonienl will give me some help with some of the details, like colors because UD uses it's own style sheet. I'll end up doing several incremental releases to improve the Azure, and Gray themes as I can work out the details. I am really liking the Azure theme!