boomam

You basically just follow some of the steps from the 'guide', from the containers bash console, leaving off steps 5 & 6. After that the container starts and stays up, and you just need to configure the json file with your options/tokens, etc.

To answer this for myself - yes the container is incomplete. After a bit of playing around, you need to do the full install of the proxy via wget/etc. within the container environment to use the container. Defeats the purpose of the container really. 😛

RE: Mattermost Push Proxy - Is the container broken in its current iteration? Downloaded, created/wget'd the config.json - still doesn't want to start - /usr/local/bin/entrypoint: exec: line 3: /mattermost-push-proxy/bin/mattermost-push-proxy: not found Missing documentation perhaps? (note, please do not link to the mattermost setup article, as it has no clear relevance to a container based install.) Thanks!

A lack of special characters would entail using a much weaker password, something im not comfortable with. Shame, would have been handy.

Anyone having issues with this at the login stage? Whether using valid username/password, or the api based username/password, it always fails to login, with "Invalid Username or password" Are there any obscure characters it doesn't like/passthrough perhaps?

Hi. Is this not a browser installation of OpenRCT? RE: forwarded ports, no, there is no need to as i am inside my own LAN.

Does anyone know if there's any clearer documentation for the OpenRCT2 container? The Docker hub page, and the Unraid template, say this on one of the variables - "The hash of the admin user (you find it on the client computer in the 'user-data/keys' folder from OpenRCT2" What on earth does this mean!? What client is it referring too, and what path to that folder? I'm guessing a lack of this variable is caused this error too: "Unable to connect to master server". Thanks!

Group folders is an addin/plugin, just reinstall it.

Yup. Confirmed myself too. To help anyone, assuming standard paths - 1. ssh to server/use web interface for shell (ssh user@IP) rm /mnt/user/appdata/nextcloud/nginx/site-confs/default Then restart the container.

That's fine, its a small price to pay to ensure that the container/built files, are otherwise 'standard'. I'll keep an eye out for the next update, and delete the file then.

Question, your last post mentioned "We plan to add this soon." - Forgive me, but are we to take this to mean that you are one of the LS.io dev's, and that this change will come in an update/by-default sometime soon? As if so, then i'm just gonna leave it be, and it can fix itself whenever that update rolls around.

You have to go to 20.0.8 RC1, and then it will offer 21.0.0 afterwards. Once done, revert back to the stable channel.

Anyone else getting "/.well-known/webfinger" & "/.well-known/nodeinfo" with 21.0.0 ? Along with "you've not specified a dialing code" ? The latter is easily fixable with a quick amendment to config, but the former, despite the same syntax as the other webdav redirects, doesn't want to work for some reason.

True, but just because you are suggesting moving it to a place that the wider industry considers to be questionable, and the platform in use is Unraid, doesn't really mean anything in regards to the community forum's domain in use Anyway, out of curiosity, are you running 6.8 or 6.9? I've a little time today and I want to see if I can work out why the redirects are getting ignored, starting with a difference in the docker package version/unraid version.

You are thinking in Unraid terms. In an actual production system that uses containers, that kind of setup of file storage would be seen as bad practice. For Unraid specifically, yes you can get away with it, but the docker.img is only 'usually' on the same disk if the user has set it to be so. Having a separate share specifically for temp files in several apps, allows the user to pick where they want said data temporarily storing, allowing the potential for choice in speed, resiliency and IOP queues.

Generally speaking, configuration storage shouldn't be used for other storage types, even if temporary. Whilst I doubt it would have a large effect for the average unraid user, in a production container environment, it would be a big no-no. For myself, I'd rather not have the extra writes on the SSD cache that has my appdata, but seeing as the redirection fails to work whatever its set to for me, its somewhat moot either way - I'm hoping its just a bug in 6.8.3, and will resolve when 6.9 gets released.

As a note, NextCloud, if unspecified, uses /tmp for temp files. So unconfigured, it will use /tmp. Re: using appdata for temp storage This to me seems somewhat inefficient, as the appdata should literally just be app data (configs), and not actual data storage for something like NextCloud. I've set mine to a custom share called 'temp'. However to note....it still doesn't work.

This doesn't sound right - you are pointing the temp files back at appdata? Defeats the idea surely? Would it not be better to store in perhaps a 'temp' share? To add for testing - on both the linuxserver/nextcloud image, and the NPM container, /tmp does not redirect inside the container to any host variable whatsoever. Very strange.

Ok, as some constructive feedback - What can we do to fix the consistent database connection issues that are prevalent with this container? Specifically what I'm referring too is that if the variables in the container lists support for the ability to specify host port, db name, db user, db password, for all intents and purposes i would expect said variables to work. But the consistent thread is that they dont and we should 'leave them blank' instead. So we either need to work out why they aren't working, or remove them from the template and specify on the readme accordingly. What would be the better route forward for this do you think? To be clear, I'm willing to help with some testing if it helps improve the container for others. 🙂

Fair enough, thanks for the update👍

That seems to have done it, almost instantly too! What was it in the end, if you don’t mind me asking?

https://imgur.com/a/n2sWrWU

No effect. Just retested as i got in, about 2-3 hours after your post - same issue. As said, i'm not worried, its not a show stopper. However it doesn't look like the other poster has confirmed the fix either, so probably still an ongoing issue i'm guessing.

Update now complete. Issue persists for me still however. Meh. Not a show stopper.

Good to hear. Can't verify my end, update fails right now, so I assume git issues. I'll give it another go later. plugin: updating: unassigned.devices.plg plugin: downloading: "https://github.com/dlandon/unassigned.devices/raw/master/unassigned.devices-2020.10.04.tgz" ... failed (Invalid URL / Server error response) plugin: wget: "https://github.com/dlandon/unassigned.devices/raw/master/unassigned.devices-2020.10.04.tgz" download failure (Invalid URL / Server error response)