CorneliousJD

I'm pretty new to docker containers in general already - i'm not sure why it pulls an old version either, but what would i need to add to the dockerfile and startup scsrips to accomplish this? Right now this is an openeats developer's dockerfile - i may be able to get him to update it so I don't have to fork.

You can't use "localhost" as the SQL host from what I recall, because that only looks inside the container. You need the IP of the host or your unraid box

I have mine setup using another user, make sure whatever user you setup has full permissions over that database in question. Also see my previous reply, your select statement showed "openeats" as the user, NOT "admin" like your variable states, so that may have something to do with it, it doesn't seem to be actually writing your intended superuser user/pass. If the select satement shows username of "openeats" again I'd try logging in with that for both user AND password. If that doesn't work try "openeats" as the username with the password you actually specified. If that doesn't work, I'd try again setting "openeats" as both the superuser username and password when setting up the container. PS, just worth mentioning, make sure you aren't yet trying to hit this from a publicly accessible URL, try from the IP:port you have it configured on to rule out any reverseproxy issues.

Your username here shows "openeats" -- try login in with user and pass of openeats maybe? It doesn't appear to have listened to your "admin" username you specified in the screenshot, the default it will make is openeats//openeats. Give that a go.

Your variables all look fine to me. If you drill down into your database anto the "auth_user" table do you see your admin user you selected in the container? If you do not see it there, then you may want to try blowing away the database itself and the appdata folder for OpenEats and force an update on the container (this will re-pull it fresh) and fire it up again, and create the database with the user. EDIT - This is what mine looks like - I'm the only user listed, and this username was my supseruser user/pass I put into the container as a variable.

Hey guys, I've been completely re-evaluating my backup strategy lately, and I'm replicating essentail appdata and assocated backups to the cloud via Duplicati, but I want to do local backups as well. My thought process was to store them on an unassigned disk, because in the event of a total system or hardware failure I could pop that one drive out and plug it into another machine and spin up a Duplicati instance and read the data from it without any real issues? But then on-array has the benefits of the data still existing in parity of the drive dies, but if unRAID itself somehow blows up then I'd lose it all the local backup data and have to pull from the cloud storage which as fees for downloading. Let me know what you guys think the best move here is. Thanks in advance!

That would be something you'd need to check in with the OpenEats developers themselves on to see if it's soemthing that can easily be modified somewhere. I don't have a way to set that though from the container side personally, sorry! That's odd, I never tried another langauge before because I don't know any, but the NODE_LOCALE variable was taken directly from here: https://openeats.readthedocs.io/en/feature-doc-update/Setting_up_env_file/ (see the very bottom) Also the Dockerfile that this is built from also includes the NODE_LOCALE variable so it should be working. Does any other language work when you try to change it to anything other than English? Or does it always show as English?

Some IRC networks wont let you connect with VPNs - I'm not speaking for LSIO here but it seems unlikely that this would happen directly

Soundsl like you want ZNC or Quassel-Core for this.

The scraper should be functional, you'll likely want to take this up with the devs on their GitHub here: https://github.com/stashapp/stash Or you can try upgrading to the beta release to see if it's been fixed/improved there, as that's where actual development is happening. You can edit the container to pull stashapp/stash:development-x86_64 But note that if you upgrade, you can't easily downgrade because it changes the database. You'd need to stick with the beta/dev build until they update the main release to be based off that new updated database.

Thanks! Do you happen to know why the other one wasn't actually pulling from an updated master file? I can't seem to figure that out. I'd like to fork just the dockerfile if I can and not have to maintain a separate OpenEats repo itself. Thanks. Although I do not believe the serving size changes will be able to parse that character and change it accordingly? If it does great, otherwise you would still need to stick with 1/2 anyways.

Interesting, I guess I'm not sure why it would be pulling such an old build when it's supposed to pull from master. Mind sharing your dockerhub repo? I can change my pull to that and if it works successfully I can just update the template in CA to pull from yours instead

I am not the dev, see first post that describes this request already The dev has already touched on working on that but it's still not working correctly at this time. I would just recommend biting the bullet and firing up a MariaDB container, it's not too tough to do.

Is your ALLOWED_HOST variable set to *? If not set it back to * and try again, also see known issues about linked recipies as well, it is known to hang currently when trying to link a recipe. 1/2 is supported just fine but ½ (the actual symbol) is not. e.g. the following are fine 0.5 cup water 1/2 cup water the following is NOT ½ cup water The last one will not work becuase it cannot proccess that as a proper quantity.

Not really, I assumed there was some new containers using up more in the image, I'm not sure what's new, but when containers update (if you ahve it scheduled then) it may be why it's filling up more around those times. I just stopped docker, added 5GB to my img file and I haven't had a warning since!

I actually use the same container, but like @jonathanm said, you could also spin up a second MariaDB instance with a different name and different appdata. I personally just use the same container, I find using a program called HeidiSQL on Windows makes it easy to connect to my MariaDB instance and add/drop databases and tables, and add users if needed too, or Adminer (which is it's own docker container in CA) can be used to do the same as well, it gives you a nice GUI to work with instead of command line for managing the databases. If you're comfortable with a little tinkering and learning along the way, you can use the same MariaDB you use for Nextcloud, otherwise just install the same container again and called it mariadb-openeats and give it an appdata with the same name and you'd be off to the races in no time!

I keep running into an issue while trying to test this container too... I just setup a fresh install of it and a fresh B2 bucket, but now I'm seeing that purges from B2 are failing as "File not present". I saw this last week too and CloudBerry support isn't being much help here honestly, I'm not sure what's going on. I just want to backup my entire /appdata/ folder at midnight every night. CrashPlan is currently doing this and is not complaining (I'm also not ever purging anything either), but I'm really trying to get away from CrashPlan and thought CloudBerry would be leaps and bounds better, but I'm not sure what's going on now, this hasn't even been up and running for a few hours yet and purges are failing?

Alright, I'm still going through some hoops getting this setup properly to give me a minimal B2 usage and also be efficient enough to give me what I need. I have it setup like this currently, and I think it's right, the goal here is to Backup CA Appdata backup files (generated weekly) and keep them for 30 days. Backup direct appdata/nextcloud/some other files as well. Only keep X days of versions. Keep latest 3 versions at minimum (even if older than X days) If anything is explictly deleted or unchecked from backup jobs, delete them from B2 after 30 days. Does this look correct to you guys? If there's a better retention that you think I should be using please let me know. I'm currently debating keeping 7 days, 14 days, or 30 days of versions.

Ah gottcha, that I do not know off hand, I would assume it does have something to do with the reverse proxy setup, but I'm not able to figure out what's missing there or what else I could do to make it work. Since the admin page is likely to be accessed so infrequently once you have users/groups setup I didn't think it was a huge deal, and I didn't have the time to sit and try and figure that one out unfortunately

Which issue specifically? Reverse proxy is easy to detect, just try it from a local isntance and that will rule out reverse proxy.

Could you edit your one post and remove those large logs if you get a chance, just makes it a very long scroll to get passed when no mobile especailly.

Same here. It's actually on the known issues in the first post. I'm not sure why as I haven't been able to gather any reason why. I haven't been able to test yet but you may be able to force version 1.5.1 or 1.4.0 and try with that? If you do and it works let me know!

For what it's worth it seems you have to add a comment. You cannot JUST do a rating.

Tested via domain on and off my home wifi and it's working good for me. I have my allowed host set to my unraid server IP and my sub.domain.com

Interesting. Yeah it just be something with that. Try blowing out the whole open eats container too when you make the DB over again. Make sure you assign a user with all rights on that db (or use root user and pass)