anethema

EDIT: Pinning to the 1.5.1 tag made it stop happening so it is definitely an issue in the latest update. Mine stopped working. invokeai just seems to do some reinstall loop then the container stops. Any idea? (I've made no other changes. My config is here: And here is the last log before the container stops:

Hey just looked at the issue and it appears that someone did make a few basic changes and got it working with the GPU. https://github.com/serge-chat/serge/issues/43#issuecomment-1792070396 Any idea if it would be possible for you to add that into your template etc to make it work ?

Ya the host access option makes no difference in my setup. It has been off for me from day 1 and if I put the unifi controller or pihole on a br0 to get their own ip, I lock up within 12-24 hours.

I'm running 6.9.2 now. Let's see if it freezes.

Awesome I also still cannot run docker containers on br0 either. It will start causing macvlan errors in syslog and eventually kernel panic. The problem also followed me from my R510 to my R720 if that helps at all.

Well just reporting back that mounting as rclone works MUCH better. Restores at full speed. The checking files and anything folder related is pretty slow, but the transfer itself is fast. So it seems like its a problem with cloudberry itself, in their B2 implementation.

I'm not holding out hope for it to be much faster, as just the repository sync is on track to take two full days. I will see about the restore once the sync is done, but it really does seem like something is broken with cloudberry itself. Maybe some setting or something, but it DOES transfer for me, just horribly slowly, and I've now verified on the unraid machine itself that it works very quickly in unraid itself.

I'm actually trying another route now. I have my B2 bucket mounted as a folder in unraid using rclone. I can copy files out of the FUSE folder at full line speed of my network, so it is def not backblaze being slow. The folder structure is just synchronizing now in cloudberry so we will see how a restore works with that.

Maybe but it is taking like 5mins to download a 100kb .png file. It really seems to be just going very slow.

It does not even create a VM for me. I get this from the helper script after I got the notification it was ready: It does not create any VM for me. EDIT: Removing the entire macinabox appdata, app, and the /mnt/user/system/custom_ovmf folder fixed this for me.

My server also crashing. The same nf_conntrack_core.c macvlan errors. It will usually handle a couple of them then kernel panic. I will try disabling all custom IPs, but is it really expected that we cannot set a static IP or the server will crash every 4-6 hours? This bug continues for my in 6.9RC2. Not sure how having the containers on a separate VLAN will help since I set them as a static IP because they need to be accessible to my normal network (unifi controller, pihole, etc)

I'm having absolutely abysmal speeds using cloudberry to pull from B2. Tried a download of files from the backblaze website myself and it goes full line speed of my internet. 2kb/s Anyone have any idea why this would be happening? Lost my plex folder but it will be a long long time restoring at this pace heh.

Just wondering if the steamcache is using an odd region? I am only getting 3-4MB/sec rather than the normal 16 on the first download(to SSD). My Steam is set to Canada - Edmonton on the downloading machine. When I download for the first time through the steamcache i get: 10.3.3.171 / - - - [14/Nov/2019:15:25:49 -0700] "GET /depot/583952/chunk/6fe88c8bc485c906703424d6dc8be0f20168823b HTTP/1.1" 200 103152 "-" "Valve/Steam HTTP Client 1.0" "MISS" "cache1-sea1.steamcontent.com" "-" So using a seattle server rather than the one I have set in steam?

My filebot has also long ago stopped scanning for folder changes. Is there any way to fix this?

I tried installing it with no luck. The following error happened: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='telegraf' --net='host' --privileged=true -e TZ="America/Phoenix" -e HOST_OS="Unraid" -e 'HOST_PROC'='/rootfs/proc/' -e 'HOST_SYS'='/rootfs/sys/' -e 'HOST_ETC'='/rootfs/etc/' -e 'HOST_MOUNT_PREFIX'='/rootfs/' -v '/var/run/utmp':'/var/run/utmp':'ro' -v '/var/run/docker.sock':'/var/run/docker.sock':'ro' -v '/':'/rootfs':'ro' -v '/sys/':'/rootfs/sys':'ro' -v '/etc/':'/rootfs/etc':'ro' -v '/proc/':'/rootfs/proc':'ro' -v '/mnt/user/appdata/telegraf/telegraf.conf/':'/etc/telegraf/telegraf.conf':'rw' -v '/mnt/user/appdata/':'/appdata/':'rw' 'telegraf:alpine' e61de4249ea43e396f7c28f26e28a357977118ad2e80763cafd8763d9fce51fd /usr/bin/docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "rootfs_linux.go:58: mounting \"/mnt/user/appdata/telegraf/telegraf.conf\" to rootfs \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a\" at \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a/etc/telegraf/telegraf.conf\" caused \"not a directory\""": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type. The command failed. Any idea? EDIT: Ah, the default container config looks like it tries to map to /etc/telegraf.conf instead of /etc/telegraf. Fixed it.

Ya it just sits there. Nothing I can do seems to make it actually detect folder changes to run again. [2018-09-22 19:35:44] FileBot: Finished running command. Exit code was 0 [2018-09-22 19:35:44] FileBot: Waiting for new change

Run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='FileBot' --net='bridge' -e TZ="America/Phoenix" -e HOST_OS="unRAID" -e 'WIDTH'='1280' -e 'HEIGHT'='720' -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'UMASK'='0000' -e 'INPUT_DIR'='/input/downloads/complete' -e 'OUTPUT_DIR'='/input' -p '3389:3389/tcp' -p '9898:8080/tcp' -v '/mnt/user/Media':'/input':'rw' -v '/mnt/user/appdata/FileBot':'/config':'rw' 'coppit/filebot' a444df103ad6a940c8b8f1c329a6062cb5e616388ff33db51b20e4efac596b71 When starting/restarting the container, it scans the input directory properly, then hardlinks the files over. When just letting it sit and monitor though, no changes are detected. This used to work and no config changes have been made since it stopped working. Thanks for the help! generalnasty-diagnostics-20180912-1826.zip

My filebot is mostly working fine, but unfortunately it has stopped detecting folder changes automatically. Any idea why that might be? If I restart the container to run it, it works fine.

Any chance you guys will make it possible to never upgrade past the 5.6.36 LTS ? 5.7x is dropping support for all their APs below the version currently being sold, so for a lot of networks this will mess us up. Not sure if it would be possible to add a "LTS" tag or something to stay on this one? I know I could just not update the docker ever again, but I am just asking due to maybe messing up and clicking the upgrade, or somehow misconfiguring the auto update plugin to do it, etc.

Ya I guess the problem is, the box is plugged into a VLAN trunk port, so there is no actual network on normal eth0. Just eth0.10 (what I want) and eth0.6 I access several vlans from different dockers so it is kind of an odd configuration, but ya there is no accessible IP from the normal eth0.

But can I specify the IP of the unraid server (10.3.3.50)? Or won't that just cause an IP conflict? I want to run in bridge mode, not assign each docker its own IP on my network.

Anyone know?

The way my setup is, my unraid server is plugged into a VLAN trunk port, and I break out a couple multiple VLANs for different reasons. But my home network is one of those. The unraid machine does not get an IP from its main network interface. So to access my dockers, I have to visit 10.3.3.50:port rather than the static I have assigned on the main interface (10.0.0.250:port). So no problem. I go into the docker setttings and change the WebUI: field from the advanced view to have the proper IP/port and everything works fine. So rather than the default: http://[IP]:[PORT:5800] I would set it to http://10.3.3.50:[PORT:5800] The problem is, the next time the container updates, this info is lost. It takes forever to go through all the dockers and change it again. Any idea how to make this behavior stay?

Hm. If you enable user authentication, it just stops working all together. I get a 500 internal server error, and the logs read as follows: Exception while invoking method 'checkPlexUser' TypeError: Cannot call method 'toLowerCase' of undefined at [object Object].Meteor.methods.checkPlexUser (server/methods/authentication/plexAuthentication.js:69:1) at maybeAuditArgumentChecks (livedata_server.js:1698:12) at livedata_server.js:708:19 at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1) at livedata_server.js:706:40 at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1) at livedata_server.js:704:46 at tryCallTwo (/app/bundle/programs/server/npm/promise/node_modules/meteor-promise/node_modules/promise/lib/core.js:45:5) at doResolve (/app/bundle/programs/server/npm/promise/node_modules/meteor-promise/node_modules/promise/lib/core.js:171:13) at new Promise (/app/bundle/programs/server/npm/promise/node_modules/meteor-promise/node_modules/promise/lib/core.js:65:3)

Ya I can't risk losing all that work by clicking the wrong button anyways. Too risky! I'll have to keep running it in a VM for now.