CraziFuzzy

Sorry I can't be of any help, but wanted to let you know that I'm having the same problem. Just found Steam Headless, and thought it'd be an excellent addition, but it just keeps going in this loop. This is with all default settings (not that I'd have any idea what to change).

So, this is part of the problem I've experienced - with there being multiple ways to do a thing, and no clear way in the UI to know how to do so. In my case, I am not running my exposed containers in host mode - as you are - they are instead running through br0, which is set with my local ipv6 prefix. This puts each docker container as another machine on my local network, and a ipv6 global address. The trick i needed to do was to make sure that the containers were assigned the same ipv6 address every time - which since it was based on the prefix and MAC address, was another 'additional parameter' that needed to be added to the container. That finally was the key to allow adding DNS entries for those machines, and making it work. And then I upgraded to unraid 7, and now, for some reason that I haven't determined yet, the mac addresses are no longer being set by the --mac-address parameter, so things are no longer remote accessible until I get through this struggle...

I switched to StarLink a few months ago, which is the first time I've dealt with a CGNAT ISP, so with that process, and wanting to get some of my self-hosted services back out to the internet, I delved for the first time into IPv6 (had always just kept it disabled previously, and stuck to v4, with port forwarding and DDNS). I'm now have a domain, and everything routing to the appropriate containers, but it was a very manual process to set that up. This was still on the 6.xx version of unRAID. I've since upgraded to the current 7.1.x, and don't see much in the way of changes on the docker networking front. Are there any improvements that have been/should be made to the docker UI to make IPv6-centric situations like this more intuitive? Getting to any v6 settings in the unraid docker UI seems to be far more cumbersome than the v4 counterparts - and I'm not sure that should be the case today and moving forward. I'm sadly, not really the person that should come up with a request list, because I genuinely have no idea how others have implemented this type of configuration.

What is the current state of this container? It appears that @coppit is no longer maintaining it, so has anyone forked it and make any updates? I noticed that Archive Search is no longer functioning, and my Motion Detector is now complaining about not having the a new enough library. My guess is this is a dependency that just needs to be updated in the dockerfile, but I'm not sure.

quick update - it seems the errors I was seeing were due to folder permissions. For some reason the folders that the containers create don't get set with permissions that those same containers can access. chmod 777'ing them got the containers to all start up.. I think.. so far... now to actually learn how to USE graylog...

So, just tried the above linked compose method and ended up with the same errors as @GTvert90 . I don't feel that this particular service should be so strangely difficult to get running.

I also have been fighting with trying to get graylog working in an Unraid docker. Seems to be a combinations of many problems with how ALL the current dockers seem to be built. For starters, you need other services up and running for Graylog to work. That being elasticsearch and mongodb. I have not gotten any of the three docker containers to actually install and 'just work'. File permissions are trying to run as root, instead of nobody, on all the containers. There also seem to be some version restrictions betweeh what version of graylog you use and what version of elasticsearch works with it. Not sure if that is the only problems, but it seems like it may be worth trying to create a container that just includes all three services rolled up together - unfortunatly, I don't know enough about any of them to take this on.

Just doing a major network topology upgrade to the house - and decided to split out my dockers... really wish DHCP worked for the docker containers... I mean.. something creates the MAC address and the IP address for them - should be able to proxy in the DHCP request as well - right? An 'outside the container' service perhaps, optional so that it doesn't need to interfere with containers that DO handle their own DHCP. In the meantime - lots of double work statically assigning container IPs and duplicating the settings in the router's DHCP Server.

Okay, thanks. Any chance of getting this noted in the docker/CA database?

Is anyone able to use minio out of the box on their unraid install right now? It seems they (minio) are saying that it won't work on unraid's array (/mnt/user) shares as unraid's shfs doesn't support O_Direct. I have tested this by mapping it to a single /mnt/disk1 so it is hitting the xfs directly, but this limits me to a single drive. It looks like minio does support adding multiple drives with some config file editing, but it also seems like they expect to be the only things on the drives for them to spread space properly. I don't THINK for my use that being limited to a single drive will be a problem, but I am wondering if anyone has come up with a more elegant solution.

So, I know that the ability to limit a share's reported free space has been a request for a while, and I know it is unlikely. I wonder, however, if it would be possible to create a vdisk or similar disk image, stored on the parity array, and mount IT as a share? This would them present anything accessing it as only having the space the image has - so applications that limit their disk use to available space would still obey that limitation. I just don't know for sure if this is readily possible on unraid.

You might go with a networked trigger from in xeoma instead of running a local command. I think it's call HTTP Request sender, sending requests to HA's http sensor.

Is there any specific thing to look for to see why a device chosen in the plugin doesn't bind to vfio, and as such, is not available to be selected in a VM? So far, I have not been able to pass through anything other than my video card (and it's associated sound). After trying differnet ACS settings, the card I'm wanting to pass through is grouped with just a PCI bridge (guessing the one it is routed through), so when they are all checked, they still don't bind.

Hmm.. and actually, it looks like there may be an issue with the version fetching in the image anyway. It is currently fetching version2.xml, which looks like they used through version 19.4.19. They now have a version3.xml with the actual 'current' version of 9.4.22.

So, while I'm here, I thought I'd ask this. What is up with the timezone setting in the xeoma docker? I noticed that my currently recording archive files are from the future, and when i connected to the container, i found that the timezone is just.. wrong. For example: root@Tower:~# date Tue Dec 3 21:27:30 PST 2019 root@Tower:~# docker exec -it fbfeacf9bf2f date Wed Dec 4 05:27:34 America 2019 Is there an environment variable for this container we can set? Xeoma seems to work 'okay' with this, as the client seems to be aware of the issue, and translates times to the timezone the client is set to, but this has got to make schedules and such complicated (I don't use any, so not sure if it's a problem in practice).