footballmad

The path I use for container configuration is /mnt/disk15/Docker-Configs. Is this wrong? Here is the result from the read only scrub (This is from the disk management page and not docker) scrub started at Sat Jul 4 16:57:41 2015, running for 2544 seconds total bytes scrubbed: 179.39GiB with 13 errors error details: csum=13 corrected errors: 0, uncorrectable errors: 0, unverified errors: 0 Would you advise that I redo this and try to correct errors? Would this in any way create more of a risk to my VM that I can't copy? Thanks

Ah ok, If I understand then the filesystem inside the docker file is BTRFS and the docker image can be stored on any file system? Thanks for the info.

Does anyone run docker on a non BTRFS file system? What are your experiences? I believe I remember reading that this file system was better to compression or maybe de-duplication but I'm willing to sacrifice that on a more stable file system for docker.

Thanks BRiT. I don't care about the docker.img but I would really like my VM back if possible. I'm running the scrub now and post the results once finished.

After a reboot the docker tab came back, however the problems with containers crashing persist. I installed v6.0.0 cleanly, formatting the flash drive beforehand, so there were no plugins. I've recreated the docker.img a few times, however I'm sure you've seen my previous posts explaining, docker runs fine for a time upon rebooting then the issues come back. How do I check if the system logs are full? There's plenty of room on the flash drive. df -h gives this, Filesystem Size Used Avail Use% Mounted on tmpfs 128M 40M 89M 31% /var/log /dev/sda1 3.8G 290M 3.5G 8% /boot /dev/md1 1.9T 1.9T 696M 100% /mnt/disk1 /dev/md2 1.9T 1.9T 13G 100% /mnt/disk2 /dev/md3 1.9T 1.5T 407G 79% /mnt/disk3 /dev/md4 3.7T 3.2T 466G 88% /mnt/disk4 /dev/md5 1.9T 1.8T 21G 99% /mnt/disk5 /dev/md6 1.9T 1.9T 14G 100% /mnt/disk6 /dev/md7 1.9T 1.8T 42G 98% /mnt/disk7 /dev/md8 1.9T 1.8T 84G 96% /mnt/disk8 /dev/md9 1.9T 1.8T 54G 98% /mnt/disk9 /dev/md10 1.9T 1.9T 1.7G 100% /mnt/disk10 /dev/md11 1.9T 1.8T 30G 99% /mnt/disk11 /dev/md12 1.9T 1.8T 54G 98% /mnt/disk12 /dev/md13 1.9T 1.4T 463G 76% /mnt/disk13 /dev/md14 1.9T 934G 930G 51% /mnt/disk14 /dev/md15 1.9T 1.1T 754G 60% /mnt/disk15 /dev/sdn1 466G 180G 286G 39% /mnt/cache shfs 30T 26T 3.3T 89% /mnt/user0 shfs 30T 27T 3.6T 89% /mnt/user /dev/loop1 1.8M 89K 1.6M 6% /etc/libvirt /dev/loop0 15G 2.3G 12G 17% /var/lib/docker /var/log/syslog gives this, (the last few lines) Jul 4 15:19:32 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:19:32 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:19:32 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:30:36 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:30:36 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:30:36 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:31:41 msstorage kernel: mdcmd (353): spindown 3 Jul 4 15:31:49 msstorage kernel: mdcmd (354): spindown 9 Jul 4 15:31:57 msstorage kernel: mdcmd (355): spindown 7 Jul 4 15:32:04 msstorage kernel: mdcmd (356): spindown 6 Jul 4 15:32:04 msstorage kernel: mdcmd (357): spindown 10 Jul 4 15:32:22 msstorage kernel: mdcmd (358): spindown 5 Jul 4 15:32:22 msstorage kernel: mdcmd (359): spindown 11 Jul 4 15:34:01 msstorage kernel: mdcmd (360): spindown 1 Jul 4 15:34:01 msstorage kernel: mdcmd (361): spindown 4 Jul 4 15:39:10 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:39:10 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:39:10 msstorage kernel: BTRFS warning (device sdn1): csum failed ino 273 off 7155044352 csum 2214257214 expected csum 3520190875 Jul 4 15:40:55 msstorage kernel: verify_parent_transid: 2 callbacks suppressed Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127549440 wanted 2290 found 1968 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127549440 wanted 2290 found 1968 Jul 4 15:40:55 msstorage kernel: BTRFS info (device loop0): no csum found for inode 264 start 0 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127549440 wanted 2290 found 1968 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127549440 wanted 2290 found 1968 Jul 4 15:40:55 msstorage kernel: BTRFS info (device loop0): no csum found for inode 264 start 4096 Jul 4 15:40:55 msstorage kernel: BTRFS warning (device loop0): csum failed ino 264 off 0 csum 3551632587 expected csum 0 Jul 4 15:40:55 msstorage kernel: BTRFS warning (device loop0): csum failed ino 264 off 4096 csum 3166042738 expected csum 0 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 126992384 wanted 2290 found 2289 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 126992384 wanted 2290 found 2289 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 126992384 wanted 2290 found 2289 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 126992384 wanted 2290 found 2289 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127926272 wanted 2290 found 1969 Jul 4 15:40:55 msstorage kernel: BTRFS (device loop0): parent transid verify failed on 127926272 wanted 2290 found 1969 Jul 4 15:40:57 msstorage kernel: mdcmd (362): spindown 2 Jul 4 15:40:58 msstorage kernel: mdcmd (363): spindown 14 Jul 4 16:00:39 msstorage kernel: mdcmd (364): spindown 13 /var/lib/docker, hmmm this is interesting, I tried to list the files here and have the same error as when I try to copy from the cache disk. root@msstorage:/var/lib/docker# ls /bin/ls: reading directory .: Input/output error

Hopefully not too off topic as it is related to my cache disk and therefore potentially my docker image. I wanted to replace my cache disk to eliminate this as the source of error, the only files that I have there that I want to keep are my VMs. One VM copied fine but I'm getting errors during the copy of the other VM (cp: error reading ‘vdisk1.img’: Input/output error) I checked the destination and specified the disk during the copy and there is plenty of room. Therefore, does anyone have am idea of how I can force the copy? Could this indicate an error with the cache disk? I ran a SMART disk check and this came up clean. Thanks

I updated my UNRAID version to 6.0.1 in the hope that would eventually fix any Docker issues (even though there is nothing in the release notes about this) but the problem persists. I can reproduce a "crash" of my containers and provide any other logs and diagnostics if this would help?

Glad it was a one off for you

Slightly reassuring to know it's not only me but sorry you're having these problems too. It'll be interesting if, after some time of your docker containers running that you try to modify a setting on one of them, that was generally what crashed the rest of my dockers and then requiring a restart of UNRAID and a recreation of the docker.img. Any others with similar problems?

There we go. msstorage-diagnostics-20150628-2245.zip

Do you want every diagnostic file? Or only docker and the log folder?

Since my last post I checked if the file /usr/local/emhttp/plugins/dynamix.docker.manager/dockerClient.php was read only and it isn't. I haven't had time to restart my server yet (this was the only solution to get the containers running again) but another container crashed (mineos). The only container that stays working is Logitech Squeezebox, which was the case before when I had these problems.

Thanks for the advise guys. I knew that using a clean docker.img file didn't lose my settings as I used the same config paths so I deleted the old docker.img and started cleanly this way. I reinstalled my containers and all worked well for a day. However when I tried to update the configuration to my beets container (which also ran ok for a day) I then "lost" the container, it's disappeared from the list. I thought this may have been the beets app so I tried to modify my "owncloud" container and tris has also disappeared from the web view in Docker. So I tried to reinstall and I have the following error message, Warning: file_put_contents(/var/lib/docker/unraid-update-status.json): failed to open stream: Read-only file system in /usr/local/emhttp/plugins/dynamix.docker.manager/dockerClient.php on line 297 Warning: file_put_contents(/var/lib/docker/unraid-update-status.json): failed to open stream: Read-only file system in /usr/local/emhttp/plugins/dynamix.docker.manager/dockerClient.php on line 453 Can anyone point me in the right direction please? I'm loving the idea of docker containers and feels this brings so much to the already excellent UNRAID, however I'm losing faith :-(

Spoke too soon.... Docker would start ok, I saw the list of containers although without any icons and the only option if I clicked on them were "Start", no edit or logs etc. I'll install them all again using a clean docker.img I had quite a lot of bad experiences using docker with UNRAID, what is the general opinion guys? Always working without issues? Sometimes? Often problematic? Thanks for your thoughts.

ok, it seems like something went wrong during the copy. I deleted the .img that I copied this morning and then recreated an empty docker.img of the same size, stopped docker, renamed this and copied the docker.img I had saved and it's all working. Thanks for your help guys.

The path is correct (see attachments) I appreciate your help.

I reinstalled my UNRAID v6.0.0 cleanly today as I was having a few issues with Docker containers, I thought maybe it was because of upgrading since the beginning of the v6 betas. So to do this as cleanly as possible I formatted my USB drive for my clean v6 installation. I moved my VMs and docker.img from the cache drive to another disk so I could format this too (I wanted to be sure it was using the latest btrfs file system). Once started and I reassigned my drives to the correct slots, I started the array and copied over the docker.img file and enabled docker in the settings with the same config as before (size and path). I installed a few plugins that have been really useful in the past (nerd tools, community applications, Dynamix system stats and docker search) It was then I noticed (it may have been before installing these however) that I have no Docker tab, I tried trying the url http://myip/Docker but htis only shows a blank page below the Limetech header. Here are the logs from when I tried starting docker, Jun 24 12:09:57 msstorage php: /usr/local/emhttp/plugins/dynamix.docker.manager/event/started;/usr/local/emhttp/plugins/dynamix.docker.manager/dockerupdate.php Jun 24 12:09:57 msstorage php: Starting Docker... Jun 24 12:09:57 msstorage kernel: BTRFS info (device loop0): disk space caching is enabled Jun 24 12:09:57 msstorage kernel: BTRFS: has skinny extents Jun 24 12:09:57 msstorage kernel: BTRFS (device loop0): bad fsid on block 20987904 Jun 24 12:09:57 msstorage kernel: BTRFS (device loop0): bad fsid on block 20987904 Jun 24 12:09:57 msstorage kernel: BTRFS: failed to read chunk root on loop0 Jun 24 12:09:57 msstorage kernel: BTRFS: open_ctree failed Jun 24 12:09:57 msstorage logger: Not starting Docker: mount error Jun 24 12:09:58 msstorage php: Updating templates... Updating info... Jun 24 12:09:58 msstorage php: Warning: stream_socket_client(): unable to connect to unix:///var/run/docker.sock (No such file or directory) in /usr/local/emhttp/plugins/dynamix.docker.manager/dockerClient.php on line 505 Jun 24 12:09:58 msstorage php: Couldn't create socket: [2] No such file or directory Done. Do you think this points to an error with my docker.img or my cache disk? The disk is old but UNRAID doesn't report any errors here. Any ideas on how I can get my docker tab back? Do you all run docker containers without any problems? The main issue that I had before was checking for containers updates then watching as most of the containers dies on me and would not restart until I restarted the UNRAID server.