Snipe-it: " Table 'snipeit.users' doesn't exist" when using docker-compose

[Borkason]

Expected Behavior

On first run, show http://localhost/setup.php without errors.

---

Actual Behavior

See error:

QueryException in Connection.php line 729:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'snipeit.users' doesn't exist
(SQL: select * from `users` where `id` = 1 and `remember_token` = lGBjg2I7lXkSe9qySnZKNhmOirGAurmqOIluEtQbUHyHjjqesOyn5hBdt4rz and `users`.`deleted_at` is null limit 1)

---

Please confirm you have done the following before posting your bug report:

• [x] I have enabled debug mode
• [x] I have read checked the Common Issues page

---

When running Snipe-IT the first time and browsing to http://localhost I see the above mentioned error message.

This is my docker-compose.yml and the command to bring it up is docker-compose up.

version: "3"

services:

  webapp:
    image: snipe/snipe-it
    ports:
      - "80:80"
    environment:
      - MYSQL_PORT_3306_TCP_ADDR=database
      - MYSQL_ROOT_PASSWORD=my_password1
      - MYSQL_DATABASE=snipeit
      - MYSQL_USER=root
      - MYSQL_PASSWORD=my_password1
      - APP_ENV=develop
      - APP_DEBUG=true
      #- APP_ENV=production
      #- APP_DEBUG=false
      - APP_KEY=base64:pHroIaO9f3J9ENqqNmc+M9IK0cW3svnVXv7Jbp34AVo=
      - APP_URL=http://localhost
      - APP_TIMEZONE=Europe/Berlin
      - APP_LOCALE=de

  database:
    image: mysql:5.6
    expose:
      - "3306"
    environment:
      - MYSQL_ROOT_PASSWORD=my_password1
      - MYSQL_DATABASE=snipeit

[Borkason]

@uberbrady can you reproduce that? Is there anything else I can provide to fix this?

[uberbrady]

Well, here's what I did to _try_ to reproduce - which I couldn't do.

I first copied that into a docker-compose.yml file.

Then I did docker-compose up -d - so it would run daemonized.

Then I pointed my browser over to http://localhost - no port number or anything, since this is port 80.

I got redirected to the setup URL - http://localhost/setup (no .php at the end!) I went through the setup. The migration part took a while, but that's expected. Then I got prompted to create a user, which I did. Then I was logged in.

And that's pretty much that - I couldn't really reproduce this directly.

One thing to try and do is to connect to the container and look for storage/logs/laravel.log. That might have some helpful clues, maybe?

Also, if you were running a MySQL server on this same box, there might be some contention over port 3306, maybe?

These are unfortunately just guesses; I don't really know Docker-Compose all that well.

[Borkason]

Thanks for your reply. When you said it worked on your device, I tested it on another computer. There it worked, too. But I don't understand what's the issue. I could have tested that earlier, but it didn't even occur to me. Sorry.

Also, if you were running a MySQL server on this same box, there might be some contention over port 3306, maybe?

That actually could be, but I didn't expose the docker machine's port 3306. But I'll be looking into that next week. Thanks so far.

I think the issue can be closed.

[ehanlon]

I've had this happen during local development, and I resolved it by clearing my browser data. It could be that the token from a previous instance was still cached in the browser.

[JonathonReinhart]

Thanks @ehanlon, that's exactly it. I, too was using docker-compose and intentionally blew away my entire database directory. When I refreshed the page in my browser, I got several exceptions related to this query:

Next Illuminate\Database\QueryException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'snipeit_corp.users' doesn't exist (SQL: select * from `users` where `id` = 1 and `remember_token` = 9FACgaMGdDAGZ8mTalBrP2l5Z2iwM4hDtkEdDLZdEp3TQUSYr8goypTx8gyS and `users`.`deleted_at` is null limit 1) in /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:647

Here's the full laravel.log.

It looks like snipe-it is going to the database to confirm my user session, but the table is missing. It'd be better if snipe-it (or laravel?) would more gracefully handle this error by just ignoring the user session, and actually rendering the /setup route.

I'd say this is a bug, but not one you'd likely hit in production.

[bricelabelle]

I'm currently testing the v5.0.0-beta-2 version and I kept running into this exact error. Opening a private browser window as @ehanlon suggested did the trick. Thanks!

[snipe]

We document that you should clear your cookies after upgrading, but I guess we can try to have setup skip the session handlers.