mirror of
https://github.com/go-vikunja/vikunja.git
synced 2026-03-11 17:48:44 -05:00
Access denied inside the DB container #21
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vikunja#21
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rheaalleen on GitHub (Nov 16, 2021).
Tried to give this a spin under docker, I saw a similar problem over on kolaente.dev but this one is even working less.
Using the docker-compose.yml from the docs, only replacing the IP of my host, the two containers come up.
The frontend has the same problems as described on other issues site:
Also the Register Button is missing, the entire layout is misaligned. I can browse there with the subpath but otherwise it wouldn't be accessible.
The problem is that with the provided docker-compose.yml from the docs the db user vikunja cant access the database, docker logs of the container show the error "Access denied for user 'vikunja'@'docker-ip' (Using password: yes)". If I exec into the container and log myself in (mysql -u vikunja -p) I get in just fine. The user vikunja isn't restricted from which host ('vikunja'@'%').
So far I have no idea why the provided standard docker-compose would do that. Any ideas?
@kolaente commented on GitHub (Nov 16, 2021):
Did you configure the api URL as described in the docs you linked?
There's a few cases of the issue you're describing in the forum:
https://community.vikunja.io/t/new-install-no-register-button
https://community.vikunja.io/t/after-fresh-install-only-access-to-the-login-page-with-red-empty-box-under-the-form-buttons
I think there's more but those were the first two I found.
@rheaalleen commented on GitHub (Nov 17, 2021):
As I mentioned, yes, I did replace the API URL. If my host would be 1.1.1.1 I would edit the line:
VIKUNJA_API_URL: http://1.1.1.1:3456/api/v1@kolaente commented on GitHub (Nov 17, 2021):
Sorry, seems like I overlooked that.
Can you verify the api is reachable at
http://1.1.1.1:3456/api/v1/info?I'm guessing the access denied comes from the mysql container not yet being ready as it can take a while to initialize. The api container will restart in that case. Does it work if you wait a while (a few minutes max)?
@rheaalleen commented on GitHub (Nov 17, 2021):
Ah, I forgot to mention that from the Frontend Docker, the logs show a 405 returned for the request to the API. That would mean that a POST was not allowed (tried to register) but at the same time that the DB container is accessible.
I'll restart both of them and wait a bit
@rheaalleen commented on GitHub (Nov 17, 2021):
Okay, either this is new or I was just too tired yesterday and didn't see it.
The Frontend and MariaDB container just start fine but the API doesn't, it's always restarting. In the logs I see that the error is
So far I didn't know that a config file was needed, so I created an empty one inside the files folder.
Then the error changes to (config file still inside files folder)
If going back to the original docker-compose.yml (./files:/app/vikunja/files) and check the config docs it says the config is named config.yml. Is this the same one since it's
Moving the file into the root folder, alongside the docker-compose.yml results in the same error as above, Config File not found and Migration failed
========================
While writing the section above I left the containers running, for some reason the API container still continues to restart but stays up between. If you check with docker ps and see it running someone could falsely assume it's working.
@kolaente commented on GitHub (Nov 17, 2021):
Is there any useful logging output from the mariadb container?
You don't need one as long as you have env variables configured. The error message is only about the file not being found, but it uses config from env variables nevertheless.
The binary is located in /app/vikunja/vikunja in the container. If you mount some folder over to that directory, there's no binary the container can run on startup. That's why it fails.
Going back to the error message :
Vikunja is looking for a config file in one of the folders
/app/vikunja(that's the root path where the binary is located),/etc/vikunjaor/app/vikunja/.config/vikunja. A config file can be either yaml or toml and should be namedconfig.ymlorconfig.toml.The
./filesmount from the original example is only to store uploaded files and others. Vikunja does not look for a config file there.The container does not have access to your host file system. It can't know that you placed a file there unless you mount it into the container.
@rheaalleen commented on GitHub (Nov 17, 2021):
Tried my best with RTFM, that's why I tinkered a bit with the docker-compose.
It's a bit confusing since some examples include the config files and others do not and it isn't clear in some points, but that's just my impression.
Forgot to say that I tried mounting it correctly, basically I just went around with the file/volumes trying for different results.
Not really, mysqld: ready for connections, some InnoDB information (no errors), and then only lines with the access denied warning.
For recap, docker-compose.yml from the docs, Host IP for the API URL edited in and a blank folder. After starting the db/files folder are generated. No config file included or mounted
@rheaalleen commented on GitHub (Nov 17, 2021):
I tried this on a different host again, prior this was under an ESXi Hypervisor, now a Synology NAS.
Screenshots are from Synology Host, NOT from the host I opened the issue for. The everything comes up but it still doesn't work. If I somehow can solve the problem on the first host that not even my db user can login there is a chance the following problem would also happen.
ESXi does get the images through a proxy and runs a Debian 10 VM where I installed docker and tried to run the docker-compose from the docks.
====== Synology Screenshots ======
API:
Maria:
Frontend:
docker ps:
@rheaalleen commented on GitHub (Nov 17, 2021):
Another update: I went ahead and tried it again on the ESXi with the docker walkthrough section. And behold, it worked 🙃
I can't fathom why this is "broken" without a proxy.
@kolaente commented on GitHub (Nov 17, 2021):
Glad it seems to work now.
Since the original issue seems to be caused by a mariadb container, you might want to try it with the postgres example. It does not make any sense why this should work with a proxy and not without one.
@kolaente commented on GitHub (Nov 22, 2021):
Closing as resolved, feel free to ping if you have other issues.
@VincentSC commented on GitHub (Sep 28, 2024):
Because there is another docker-compose where you exposed the database to the proxy. So check with
docker container ls | grep "db"and see none of these are exposed to the proxy