timfacchin

Works for me now. Thanks so much! I needed to delete the container and the config folder to allow it to rebuild. Then I just adopted my old instance's backup and voila. That did the trick for me in case that helps anybody.

I'm having the same issue, I think. After adding the .ui_info file to my Windows PC AND adding the serviceHost IP address to ui.properties it connects to the server again but requires a password to launch the client. When I enter the password it says "Unable to connect, check your network." I tried logging in through their website to adjust the password requirement on Code 42's end but it shows in my server config as not requiring the password to launch client. Not sure on that one.

Hi all, just wanted to post an update for anybody else having this Docker issue. My problem came back after another beta update. Turns out that Docker (some containers, not all) didn't like having my appdata folder in a User share, even though it was designated as cache only. Once I changed the Container configs to point to /mnt/cache/appdata/ instead of /mnt/user/appdata/ things started to work happily again. Came across this tip on another thread and that did the trick. Hopefully having this in another spot will help the next person out.

Well, having Docker down was beginning to get really inconvenient so I ended up rebuilding the server from scratch tonight and everything recreated properly. I ended up moving each container's appdata folder over one by one just in case there was a problem within and they all worked really well. Thanks very much for the help! Tim

Here's the syslog. Please let me know if there's anything you'd like me to try (add/remove a container, recreate the docker.img, etc...) and then run another syslog. syslog.zip

I'm sure you're trying to help and appreciate the reply...I know a fair bit about what I'm doing but this ended up being a lot of things just happening to occur at once. Upon looking at my original write-up here (quickly done while leaving work) I realize I didn't properly indicate what happened in the correct order. It's pretty bad off, in fact...my apologies. I've tried many things and the exact order of them is beginning to blur in my head with all of the rebuild/pre-clear/drive-shipping time. The things that I did all took place for a reason and the way I wrote it up does sound pretty bad, you're right. Let me try to clarify. Absolutely understood. My parity and all other drives were happily working the entire time. The drive I added originally was pre-cleared and just, I mean JUST added when I realized the other one had failed, hence the reason I didn't just use the new drive as a replacement and then bump up the storage with a different drive later after all was cool. I could've created a new disk config but as I had never done that without a full OS reinstall I wasn't sure what else that would be wiped config-wise, especially with one already failed drive, so I decided against messing around too much and just ordered an additional replacement drive right away. Totally. The reason I copied the data off of the simulated disk is because I had just added a larger, empty drive to the array and it would be two days before my replacement arrived. As you said, data is king here so once it was copied I felt better. That's all. Replacement drive was added in place of the failed disk two days later and all was right in the world of drives. Yes, I went from the latest beta (Beta 15) to RC2 directly in the interest of troubleshooting my docker issue. I had run out of ideas on getting the docker issue resolved with the .img and drive scrubs, .img rebuild, container re-adds, and permissions checking, I had my data copied off onto the new array drive so I didn't care too much about a drive rebuild, and the failed drive's replacement was pre-clearing (83 hours) in another computer so I could reboot while troubleshooting docker without losing my progress. At that point I figured hey, what the heck...might as well upgrade in case that fixes it. The risk really was minimal even though my original write-up sounds pretty bad. Sorry about that. As I said in my original post, I don't believe what's going on is related to the drives at all as they all acted, restored, parity-sync'd, and expanded my array as intended...I only added the details in case it would help get to the bottom of my issue. I expect either the Docker issue is a result of the several reboots, something along the lines of that BTRFS bug (not likely as I've already switched the cache drive to XFS), or something to do with the initial drive failure and general unhappiness. Hopefully I've redeemed myself a bit with the clarification. Thank you again for any suggestions you may have.

I should also add that the appdata folder (in which my docker container lives) is primarily nobody:users/777 while a few are root:root/777. The ones that are root:root had originally been that way when they were working so I didn't go messing with any permissions or ownership. Also, appdata backups were copied with permissions using "rsync -a" in both directions so everything should have (unless I blew it) been preserved. Thanks again!

Hi all, I'm hoping you can help. It's a long story and much of this is probably unrelated but I'll try and lay out the full picture here: 1. Purchased a 5tb drive to add to array. 2. During pre-clear operation a different drive (3tb) fails. 3. Purchased second 5tb drive to replace failed 3tb. 4. Add 5tb to array as additional drive, not failed drive replacement (I had already committed that drive to a different slot) 5. Restored 3tb files from array (missing drive) to the new drive successfully just in case. 6. Pre-clear second 5tb as replacement for failed 3tb. 7. During the pre-clear of the second drive I notice that I'm having trouble accessing certain Docker apps (Sonarr, Crashplan, Couchpotato) while others seem to work (SABnzbd). 8. Successfully restore failed drive to new 5tb. Somewhere along the way on one of my several reboots for drive swapping I upgraded the OS to the 6RC2 build...I believe it was just prior to the second drive's pre-clear so things should have been ok but who knows... I know I probably did too many things at once but hey, multitasking, right? Now, the Docker problem is my real problem and I can't seem to get around it. It started by the docker container logs complaining about not having enough space (space or permissions?). I checked the docker.img file and there was space left but figured I have space on my cache drive, might as well expand the image. I stopped Docker and changed the img from 10gb to 50gb, via the webgui. It expanded properly but did not help the problem. I ran a Scrub (read only and without the -r) on both the docker.img AND the cache drive. No errors found, no help. Then I deleted the docker.img and recreated another 50gb image. The image file created itself as it should've but installing the apps would fail complaining about space (permissions?) again. I came across some mention of a bug similar to this with BTRFS on the cache drive and docker freaking out. I copied my appdata to an array disk temporarily and reformatted my cache drive as XFS. Rebuilt a new docker.img and added a new container from a template. Same issue. Warning: mkdir(): No space left on device in /usr/local/emhttp/plugins/dynamix.docker.manager/createDocker.php on line 23 Warning: chown(): No such file or directory in /usr/local/emhttp/plugins/dynamix.docker.manager/createDocker.php on line 24 Warning: chgrp(): No such file or directory in /usr/local/emhttp/plugins/dynamix.docker.manager/createDocker.php on line 25 Pulling image: needo/nzbdrone:latest IMAGE ID [d0a4debf598d]: Pulling image (latest) from needo/nzbdrone. Pulling image (latest) from needo/nzbdrone, endpoint: https://registry-1.docker.io/v1/. Pulling dependent layers. IMAGE ID [511136ea3c5a]: Download complete. IMAGE ID [b18d0a2076a1]: Download complete. IMAGE ID [67b66f26d423]: Download complete. IMAGE ID [25c4824a5268]: Download complete. IMAGE ID [8b1c48305638]: Download complete. IMAGE ID [c900195dcbf3]: Download complete. IMAGE ID [6b4e8a7373fe]: Download complete. IMAGE ID [c27763e1f3e5]: Download complete. IMAGE ID [9d9561782335]: Download complete. IMAGE ID [bad562ead0dc]: Download complete. IMAGE ID [d5199f68b2fe]: Download complete. IMAGE ID [64463062ff22]: Download complete. IMAGE ID [cf39b476aeec]: Download complete. IMAGE ID [73e86888b43e]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [3ad85d4d3739]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [fc344588ce53]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [f0260f02b760]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [af74d0b0878d]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [c81f05bcacc8]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [47a341afdc82]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [02b352c3c9c1]: Pulling metadata. Pulling fs layer. Downloading 100% of 293 B. Download complete. IMAGE ID [1c503d6206dd]: Pulling metadata. Pulling fs layer. Downloading 100% of 294 B. Download complete. IMAGE ID [80c4ce61569a]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [432ab5153e94]: Pulling metadata. Pulling fs layer. Downloading 100% of 32 B. Download complete. IMAGE ID [0ee44465b887]: Pulling metadata. Pulling fs layer. Downloading 100% of 665 B. Download complete. IMAGE ID [d0a4debf598d]: Pulling metadata. Pulling fs layer. Downloading 100% of 52 MB. Download complete. Status: Downloaded newer image for needo/nzbdrone:latest. TOTAL DATA PULLED: 52 MB Command: root@localhost:# /usr/bin/docker run -d --name="Sonarr" --net="bridge" -e TZ="America/New_York" -p 8989:8989/tcp -v "/mnt/user/appdata/sonarr/":"/config":rw -v "/mnt/user/Downloads/TV Downloads/":"/downloads":rw -v "/mnt/user0/TV Shows/":"/tv":rw needo/nzbdrone time="2015-05-18T14:44:57-04:00" level=fatal msg="Error response from daemon: Could not create local directory '/mnt/user/appdata/sonarr/' for bind mount: mkdir /mnt/user/appdata/sonarr/: no space left on device!" The command failed. At this point I'm coming up short on additional ideas short of a full rebuild which I don't particularly care to do. Any ideas or suggestions on what to try would be incredibly helpful. Please bear in mind that I'm a bit of a Docker beginner so hopefully I'm not missing anything obvious. Thank you very much! Tim