July 23, 20169 yr I'm using /mnt/cache folder, and i get this on 6.2 RC2 [pre]Pulling image: linuxserver/unifi:latest IMAGE ID [latest]: Pulling from linuxserver/unifi. IMAGE ID [f069f1d21059]: Already exists. IMAGE ID [ecbeec5633cf]: Already exists. IMAGE ID [ea6f18256d63]: Already exists. IMAGE ID [54bde7b02897]: Already exists. IMAGE ID [e93d64ee804b]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [40babc1abf0e]: Pulling fs layer. Downloading 100% of 216 MB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [7fd1a57a39f5]: Pulling fs layer. Downloading 100% of 894 B. Verifying Checksum. Download complete. Extracting. Pull complete. TOTAL DATA PULLED: 216 MB Error: layers from manifest don't match image configuration[/pre]
July 23, 20169 yr I'm using /mnt/cache folder, and i get this on 6.2 RC2 [pre]Pulling image: linuxserver/unifi:latest IMAGE ID [latest]: Pulling from linuxserver/unifi. IMAGE ID [f069f1d21059]: Already exists. IMAGE ID [ecbeec5633cf]: Already exists. IMAGE ID [ea6f18256d63]: Already exists. IMAGE ID [54bde7b02897]: Already exists. IMAGE ID [e93d64ee804b]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [40babc1abf0e]: Pulling fs layer. Downloading 100% of 216 MB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [7fd1a57a39f5]: Pulling fs layer. Downloading 100% of 894 B. Verifying Checksum. Download complete. Extracting. Pull complete. TOTAL DATA PULLED: 216 MB Error: layers from manifest don't match image configuration[/pre] Delete the docker.img file. Recreate it. Re-add your apps via CA's Previous Apps Section. Back in business. Known issue and already fixed.
July 23, 20169 yr Known issue regarding docker and unraid, not this container. Just wanted to make that clear... Sent from my LG-H815 using Tapatalk
July 23, 20169 yr Thank you, i did search for "Error: layers from manifest don't match image configuration" but did not come up with the right results it seems. Thank you. Good chance to move my appdata as well!
July 29, 20169 yr I know this has been rejected already, but adding an ability to run the beta stream would be awesome. Ubnt is awfully slow adding new features that should have been included day 1 and the beta code is the only way to get them in a reasonable timeframe. I caved and bought 4 USGs and I'd really like to use the custom firewall options and not need to write a ridiculous json file. Sent from my 6055Y using Tapatalk
July 30, 20169 yr I've installed the docker, however i cannot find my AP on the network. From my desktop, i can see it via the unifi program and unifi-discover. Below is what i see in the logs. OpenJDK 64-Bit Server VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/amd64/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
July 30, 20169 yr I've installed the docker, however i cannot find my AP on the network. Have you removed the AP's from your desktop Unifi and run set inform to tell them about the new controller? http://lime-technology.com/forum/index.php?topic=43803.msg420468#msg420468
July 30, 20169 yr I've installed the docker, however i cannot find my AP on the network. Have you removed the AP's from your desktop Unifi and run set inform to tell them about the new controller? http://lime-technology.com/forum/index.php?topic=43803.msg420468#msg420468 Well done sir. I was actually able to do the setinform from the unifi discover utility. Everything is up and running. Thanks!
August 13, 20169 yr I had the same problem with this Docker as a few other people have had, but that I've not seen a definitive solution for, and I thought I'd document the best solution I've come up with. I was having an issue where the Docker would start, but the web UI would fail to become accessible. Looking at the log files, the issue was with MongoDB, which was giving the error: Fri Aug 12 18:22:34.017 [initandlisten] LogFile::synchronousAppend failed with 8192 bytes unwritten out of 8192 bytes; b=0x35d4000 errno:22 Invalid argument Fri Aug 12 18:22:34.017 [initandlisten] Fatal Assertion 13515 This also resulted in the following errors appearing in the unRAID system log: Aug 12 18:22:34 fileserver shfs/user: shfs_write: write: (22) Invalid argument As best as I can tell, the issue is that the MongoDB service is trying to write data to the mapped folder, but the operation it's trying to perform is unsupported by the unRAID file system. (This may be a completely incorrect analysis!) I believe some people have mitigated this by having the docker data stored on an SSD instead of on the main array, but I haven't yet added an SSD to my setup, so I can only store the data on the main array. However, by changing the config path mapping from /mnt/user/appdata/unifi to /mnt/disk1/appdata/unifi, I was able to successfully start the docker. I guess that because MongoDB is now directly accessing the ext4 filesystem on the drive, it can perform whatever operation it's trying to do successfully. This might be worth documenting for others who don't have an SSD and map the config path directly to the main array. I've seen a few reports of this error in this thread and in some of the other Unifi docker support threads (it doesn't appear to be specific to the LinuxServer image, but to any Docker image that runs MongoDB and maps its folders).
August 13, 20169 yr This is I believe a problem with the FUSE file system of Unraid and why we always recommend using disk shares to specify appdata rather than user shares. Sent from my LG-H815 using Tapatalk
August 13, 20169 yr Good to know, thanks! I'm new to unRAID and hadn't come across that advice before, this was the first docker image that I've had issues with.
September 16, 20169 yr just upgraded to 6.2 and doing my docker updates However this container is the only one I cant update I get this error: "Error: layers from manifest don't match image configuration" restarted docker and i get the same thing
September 16, 20169 yr just upgraded to 6.2 and doing my docker updates However this container is the only one I cant update I get this error: "Error: layers from manifest don't match image configuration" restarted docker and i get the same thing http://lime-technology.com/forum/index.php?topic=40937.msg481138#msg481138
September 16, 20169 yr just upgraded to 6.2 and doing my docker updates However this container is the only one I cant update I get this error: "Error: layers from manifest don't match image configuration" restarted docker and i get the same thing http://lime-technology.com/forum/index.php?topic=40937.msg481138#msg481138 Even if its just the single container? All the others upgraded without issues
September 16, 20169 yr just upgraded to 6.2 and doing my docker updates However this container is the only one I cant update I get this error: "Error: layers from manifest don't match image configuration" restarted docker and i get the same thing http://lime-technology.com/forum/index.php?topic=40937.msg481138#msg481138 Even if its just the single container? All the others upgraded without issues Try as I might, I could never replicate the issue, so I couldn't ever play around with other possible solutions. The FAQ entry is a solution, and only costs you a couple of minutes in download time. But if you're going to try anything you would delete the container and image and then it in again.
September 16, 20169 yr Try as I might, I could never replicate the issue, so I couldn't ever play around with other possible solutions. The FAQ entry is a solution, and only costs you a couple of minutes in download time. But if you're going to try anything you would delete the container and image and then it in again. Just got home from work, and wanted to try something simpler before I killed my docker.img and reinstalled all dockers. Clicked on the app remove also remove image yes delete it reinstalled in CA works perfect now. Hopefully they do edit the second post on the announcement and list the issues and simple fixes that we are having. thanks again for pointing me to that. I missed that in the FAQ when I had a quick look over it last night
September 19, 20169 yr Version UniFi 5.2.7 is officially out. their apt repository is currently reporting back as unsigned... until they remedy that, no update.
September 19, 20169 yr Version UniFi 5.2.7 is officially out. Change log : http://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-5-2-7-is-released/ba-p/1680663
September 19, 20169 yr Try as I might, I could never replicate the issue, so I couldn't ever play around with other possible solutions. The FAQ entry is a solution, and only costs you a couple of minutes in download time. But if you're going to try anything you would delete the container and image and then it in again. Just got home from work, and wanted to try something simpler before I killed my docker.img and reinstalled all dockers. Clicked on the app remove also remove image yes delete it reinstalled in CA works perfect now. Hopefully they do edit the second post on the announcement and list the issues and simple fixes that we are having. thanks again for pointing me to that. I missed that in the FAQ when I had a quick look over it last night this post: https://github.com/docker/distribution/issues/1439#issuecomment-237999672 has the fix which worked perfectly for me without having to reinstall everything... you can just log in using SSH and clear the cache (details below): The existing layers may be an important piece of the puzzle. I think what's happening is that one of the existing layers was downloaded by an older version of Docker that did not save tar-split metadata. The migration to content-addressability computed an ID for the layer, but this doesn't match the ID that comes directly from the tar. The migration also prepopulated the mapping between the layer digest and the artifact digest in /var/lib/docker/image/*/distribution . Pulling another image that uses the affected layer will try to use this layer digest from the migration, but that digest turns out to be wrong, so the pull fails. If this is correct, deleting /var/lib/docker/image/*/distribution should fix your problem pulling maxpowa/npomf:latest. This is just a cache, so it should be safe to remove (removing it will just cause extra data to be transfered during pushes and pulls until the cache is repopulated).
September 19, 20169 yr Version UniFi 5.2.7 is officially out. Change log : http://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-5-2-7-is-released/ba-p/1680663 their apt is still broken, lol. I'll clarify... the repository information in the link in the changelog for 5.2.7 is the same as the update to 5 when that came out. at present the stable repository works, installs unifi all 4.8.20-8422 the unifi5 repo deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti is the one that comes back as being unsigned.
September 19, 20169 yr Not complaining, or begging for an instant update. Just thought the changelog was relevant. As newer version without a changelog is just a larger number
Archived
This topic is now archived and is closed to further replies.