Active user getting account disabled message

Running 0.37.0.2

I have a Google SSO user getting “Your account is disabled” on login. Their account is not deactivated in the Admin section of Metabase. They believe they are using the correct email address to log in, and I am assuming the error message would be different if there were no corresponding account. Any thoughts on what this could be?

I tried deactivating + reactivating without success. It seems like deactivation is not immediate so I will try letting it sit there a bit longer before re-activating also.

Hi @frangfrang
Please post “Diagnostic Info” from Admin > Troubleshooting.
Latest release is 0.37.3
Check the log for more detailed error message - Admin > Troubleshooting > Logs.
When you de/activate a user, it is immediate, so no reason to wait.

Diagnostic info:

{
  "browser-info": {
    "language": "en-US",
    "platform": "MacIntel",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.7+10",
    "java.vendor": "AdoptOpenJDK",
    "java.vendor.url": "https://adoptopenjdk.net/",
    "java.version": "11.0.7",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.7+10",
    "os.name": "Linux",
    "os.version": "4.14.109-80.92.amzn1.x86_64",
    "user.language": "en",
    "user.timezone": "GMT"
  },
  "metabase-info": {
    "databases": [
      "postgres",
      "h2"
    ],
    "hosting-env": "elastic-beanstalk",
    "application-database": "postgres",
    "application-database-details": {
      "database": {
        "name": "PostgreSQL",
        "version": "10.13"
      },
      "jdbc-driver": {
        "name": "PostgreSQL JDBC Driver",
        "version": "42.2.8"
      }
    },
    "run-mode": "prod",
    "version": {
      "date": "2020-10-26",
      "tag": "v0.37.0.2",
      "branch": "release-x.37.x",
      "hash": "ba7be09"
    },
    "settings": {
      "report-timezone": "US/Central"
    }
  }
}

I think I found a reference to the user’s login attempt in the logs (changed his name to John Doe below). It seems to suggest the Google authentication was successful.

[9f50582d-bae5-470f-8a13-a5c07fa66b9b] 2020-12-08T14:38:02-06:00 DEBUG metabase.middleware.log POST /api/card/2309/query 202 [ASYNC: completed] 240.1 ms (5 DB calls) App DB connections: 0/15 Jetty threads: 2/50 (4 idle, 0 queued) (118 total active threads) Queries in flight: 1 (0 queued)
[9f50582d-bae5-470f-8a13-a5c07fa66b9b] 2020-12-08T14:38:02-06:00 DEBUG metabase.middleware.log POST /api/card/2399/query 202 [ASYNC: completed] 464.7 ms (6 DB calls) App DB connections: 1/15 Jetty threads: 2/50 (4 idle, 0 queued) (118 total active threads) Queries in flight: 0 (0 queued)
[0fa3e845-3117-45db-8564-74aeaa235163] 2020-12-08T14:38:03-06:00 DEBUG metabase.middleware.log POST /api/card/2305/query 202 [ASYNC: completed] 738.2 ms (6 DB calls) App DB connections: 1/15 Jetty threads: 2/50 (4 idle, 0 queued) (123 total active threads) Queries in flight: 1 (0 queued)
[0fa3e845-3117-45db-8564-74aeaa235163] 2020-12-08T14:38:03-06:00 DEBUG metabase.middleware.log POST /api/card/1408/query 202 [ASYNC: completed] 785.3 ms (6 DB calls) App DB connections: 1/15 Jetty threads: 2/50 (4 idle, 0 queued) (123 total active threads) Queries in flight: 0 (0 queued)
[0fa3e845-3117-45db-8564-74aeaa235163] 2020-12-08T14:38:04-06:00 DEBUG metabase.middleware.log GET /api/pulse/preview_card_info/3086 200 17.8 ms (7 DB calls) App DB connections: 1/15 Jetty threads: 3/50 (4 idle, 0 queued) (123 total active threads) Queries in flight: 0 (0 queued)
[9f50582d-bae5-470f-8a13-a5c07fa66b9b] 2020-12-08T14:38:05-06:00 INFO metabase.api.session Successfully authenticated Google Auth token for: John Doe 
[9f50582d-bae5-470f-8a13-a5c07fa66b9b] 2020-12-08T14:38:05-06:00 DEBUG metabase.middleware.log POST /api/session/google_auth 400 181.6 ms (4 DB calls) 
{:errors {:account "Your account is disabled."}}

Is there a separate disabled state for user accounts (distinct from deactivated)?

@frangfrang Are you saying that the user is not disabled in Metabase > Admin > People?
I have never seen that before.
Could it be that there’s different casing (lowercase, uppercase) in the Google user vs the Metabase user?

I would recommend that you rename the email of the existing user and have the user login again, so it will create a new user. You can edit that in the application database table core_user. Make sure you have backups first.

Yeah, the user is not deactivated in Metabase Admin. I don’t administrate the Google accounts so I cannot be sure, but the workaround you suggest sounds like it will work. Thanks!

I also experience the same problem with various users.

  • Some users have deactivated user accounts with a different email address but with the same first-last name
  • Other users experiencing this issue only have one Metabase account, all of them active
  • All users have active G Suite accounts

Found in logs:

[51abeb3d-4184-4e00-b4e3-e2a92d4e72f1] 2020-12-22T13:41:08+01:00 INFO metabase.api.session Successfully authenticated Google Auth token for: Foo Bar
[51abeb3d-4184-4e00-b4e3-e2a92d4e72f1] 2020-12-22T13:41:08+01:00 DEBUG metabase.middleware.log POST /api/session/google_auth 400 54.0 ms (4 DB calls) 
{:errors {:account "Your account is disabled."}}

Diagnostic info:

{
  "browser-info": {
    "language": "en-US",
    "platform": "MacIntel",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.7+10",
    "java.vendor": "AdoptOpenJDK",
    "java.vendor.url": "https://adoptopenjdk.net/",
    "java.version": "11.0.7",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.7+10",
    "os.name": "Linux",
    "os.version": "4.15.0-48-generic",
    "user.language": "en",
    "user.timezone": "GMT"
  },
  "metabase-info": {
    "databases": [
      "mysql",
      "postgres"
    ],
    "hosting-env": "unknown",
    "application-database": "h2",
    "application-database-details": {
      "database": {
        "name": "H2",
        "version": "1.4.197 (2018-03-18)"
      },
      "jdbc-driver": {
        "name": "H2 JDBC Driver",
        "version": "1.4.197 (2018-03-18)"
      }
    },
    "run-mode": "prod",
    "version": {
      "date": "2020-12-17",
      "tag": "v0.37.4",
      "branch": "release-x.37.x",
      "hash": "e0d5287"
    },
    "settings": {
      "report-timezone": "Europe/Berlin"
    }
  }
}

@thomasglas
Metabase only uses first/last name for display - it’s not part of the login.
Migrate away from H2 if you are using Metabase in production:
https://www.metabase.com/docs/latest/operations-guide/migrating-from-h2.html
Then check the application database table core_user and check all the email addresses compared to Google - difference in casing could be the problem perhaps?

1 Like

Hi @frangfrang @thomasglas

Just wondering, did you ever resolve this issue? We are experiencing the same issue for one of our users and have tried deactivating and reactivating the account, tried different browsers, etc.

The unusual thing is that Metabase updates the “Last Login” for this user after receiving the “Your account is disabled.” error.

We have many Metabase users and it’s only happening for this particular user.

@robrien Please post “Diagnostic Info” from Admin > Troubleshooting.
Is the user enabled on Google?
Is the user enabled on Metabase?
Do you have multiple occurrences of the user in core_user?
Are there any difference in casing (uppercase, lowercase) of the email in core_user versus Google?

Hi @robrien @flamber, I did manage to resolve it but never got to write down what I faced while working on it. Here we go:

TL;DR: migrating away from H2 solved it but ran into DB schema issues that required dirty fixes while running the migration script

So I basically started by following the migration guide and preparing the steps until step 3.
While running the command in step 3 I ran into the following exception:

Transfering 1082 instances of Revision....BatchUpdateException:
 Message: (conn=9718450) Data too long for column 'object' at row 1
 SQLState: 22001
 Error Code: 1406
java.sql.BatchUpdateException: (conn=9718450) Data too long for column 'object' at row 1
	at org.mariadb.jdbc.MariaDbStatement.executeBatchExceptionEpilogue(MariaDbStatement.java:324)
	at org.mariadb.jdbc.ClientSidePreparedStatement.executeBatch(ClientSidePreparedStatement.java:301)
	at clojure.java.jdbc$execute_batch.invokeStatic(jdbc.clj:598)
	at clojure.java.jdbc$execute_batch.invoke(jdbc.clj:591)
	at clojure.java.jdbc$db_do_execute_prepared_statement$fn__19176.invoke(jdbc.clj:1057)
	at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:860)
	at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
	at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:789)
	at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
	at clojure.java.jdbc$db_do_execute_prepared_statement.invokeStatic(jdbc.clj:1056)
	at clojure.java.jdbc$db_do_execute_prepared_statement.invoke(jdbc.clj:1042)
	at clojure.java.jdbc$db_do_prepared.invokeStatic(jdbc.clj:1080)
	at clojure.java.jdbc$db_do_prepared.invoke(jdbc.clj:1060)
	at clojure.java.jdbc$insert_cols_BANG_.invokeStatic(jdbc.clj:1594)
	at clojure.java.jdbc$insert_cols_BANG_.invoke(jdbc.clj:1585)
	at clojure.java.jdbc$insert_multi_BANG_.invokeStatic(jdbc.clj:1651)
	at clojure.java.jdbc$insert_multi_BANG_.invoke(jdbc.clj:1619)
	at metabase.cmd.load_from_h2$insert_chunk_BANG_.invokeStatic(load_from_h2.clj:148)
	at metabase.cmd.load_from_h2$insert_chunk_BANG_.invoke(load_from_h2.clj:143)
	at metabase.cmd.load_from_h2$insert_entity_BANG_.invokeStatic(load_from_h2.clj:159)
	at metabase.cmd.load_from_h2$insert_entity_BANG_.invoke(load_from_h2.clj:153)
	at metabase.cmd.load_from_h2$load_data_BANG_.invokeStatic(load_from_h2.clj:167)
	at metabase.cmd.load_from_h2$load_data_BANG_.invoke(load_from_h2.clj:162)
	at metabase.cmd.load_from_h2$load_from_h2_BANG_$fn__73951.invoke(load_from_h2.clj:259)
	at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:807)
	at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
	at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:852)
	at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
	at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:789)
	at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
	at metabase.cmd.load_from_h2$load_from_h2_BANG_.invokeStatic(load_from_h2.clj:247)
	at metabase.cmd.load_from_h2$load_from_h2_BANG_.invoke(load_from_h2.clj:236)
	at clojure.lang.Var.invoke(Var.java:384)
	at metabase.cmd$load_from_h2.invokeStatic(cmd.clj:41)
	at metabase.cmd$load_from_h2.invoke(cmd.clj:34)
	at metabase.cmd$load_from_h2.invokeStatic(cmd.clj:37)
	at metabase.cmd$load_from_h2.invoke(cmd.clj:34)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.core$apply.invoke(core.clj:660)
	at metabase.cmd$run_cmd$fn__73464.invoke(cmd.clj:168)
	at metabase.cmd$run_cmd.invokeStatic(cmd.clj:168)
	at metabase.cmd$run_cmd.invoke(cmd.clj:164)
	at clojure.lang.Var.invoke(Var.java:388)
	at metabase.core$run_cmd.invokeStatic(core.clj:150)
	at metabase.core$run_cmd.invoke(core.clj:148)
	at metabase.core$_main.invokeStatic(core.clj:172)
	at metabase.core$_main.doInvoke(core.clj:167)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at metabase.core.main(Unknown Source)
Caused by: java.sql.SQLSyntaxErrorException: (conn=9718450) Data too long for column 'object' at row 1
	at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.createException(ExceptionFactory.java:62)
	at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.create(ExceptionFactory.java:153)
	at org.mariadb.jdbc.MariaDbStatement.executeBatchExceptionEpilogue(MariaDbStatement.java:320)
	... 50 more
Caused by: org.mariadb.jdbc.internal.util.exceptions.MariaDbSqlException: Data too long for column 'object' at row 1
	at org.mariadb.jdbc.internal.util.exceptions.MariaDbSqlException.of(MariaDbSqlException.java:34)
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.exceptionWithQuery(AbstractQueryProtocol.java:194)
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.access$000(AbstractQueryProtocol.java:108)
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol$1.handleResultException(AbstractQueryProtocol.java:687)
	at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:159)
	at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:68)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: Data too long for column 'object' at row 1
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.readErrorPacket(AbstractQueryProtocol.java:1688)
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.readPacket(AbstractQueryProtocol.java:1550)
	at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.getResult(AbstractQueryProtocol.java:1513)
	at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:150)
	... 5 more
Command failed with exception: (conn=9718450) Data too long for column 'object' at row 1

Changed the object column in the revisions table to a LONGTEXT and ran the script again until I encountered the next exception:

Transfering 343 instances of Card....BatchUpdateException:
Message: (conn=9718536) Data too long for column 'dataset_query' at row 1
SQLState: 22001
Error Code: 1406
java.sql.BatchUpdateException: (conn=9718536) Data too long for column 'dataset_query' at row 1
at org.mariadb.jdbc.MariaDbStatement.executeBatchExceptionEpilogue(MariaDbStatement.java:324)
at org.mariadb.jdbc.ClientSidePreparedStatement.executeBatch(ClientSidePreparedStatement.java:301)
at clojure.java.jdbc$execute_batch.invokeStatic(jdbc.clj:598)
at clojure.java.jdbc$execute_batch.invoke(jdbc.clj:591)
at clojure.java.jdbc$db_do_execute_prepared_statement$fn__19176.invoke(jdbc.clj:1057)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:860)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:789)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
at clojure.java.jdbc$db_do_execute_prepared_statement.invokeStatic(jdbc.clj:1056)
at clojure.java.jdbc$db_do_execute_prepared_statement.invoke(jdbc.clj:1042)
at clojure.java.jdbc$db_do_prepared.invokeStatic(jdbc.clj:1080)
at clojure.java.jdbc$db_do_prepared.invoke(jdbc.clj:1060)
at clojure.java.jdbc$insert_cols_BANG_.invokeStatic(jdbc.clj:1594)
at clojure.java.jdbc$insert_cols_BANG_.invoke(jdbc.clj:1585)
at clojure.java.jdbc$insert_multi_BANG_.invokeStatic(jdbc.clj:1651)
at clojure.java.jdbc$insert_multi_BANG_.invoke(jdbc.clj:1619)
at metabase.cmd.load_from_h2$insert_chunk_BANG_.invokeStatic(load_from_h2.clj:148)
at metabase.cmd.load_from_h2$insert_chunk_BANG_.invoke(load_from_h2.clj:143)
at metabase.cmd.load_from_h2$insert_entity_BANG_.invokeStatic(load_from_h2.clj:159)
at metabase.cmd.load_from_h2$insert_entity_BANG_.invoke(load_from_h2.clj:153)
at metabase.cmd.load_from_h2$load_data_BANG_.invokeStatic(load_from_h2.clj:167)
at metabase.cmd.load_from_h2$load_data_BANG_.invoke(load_from_h2.clj:162)
at metabase.cmd.load_from_h2$load_from_h2_BANG_$fn__73951.invoke(load_from_h2.clj:259)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:807)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:852)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:789)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:776)
at metabase.cmd.load_from_h2$load_from_h2_BANG_.invokeStatic(load_from_h2.clj:247)
at metabase.cmd.load_from_h2$load_from_h2_BANG_.invoke(load_from_h2.clj:236)
at clojure.lang.Var.invoke(Var.java:384)
at metabase.cmd$load_from_h2.invokeStatic(cmd.clj:41)
at metabase.cmd$load_from_h2.invoke(cmd.clj:34)
at metabase.cmd$load_from_h2.invokeStatic(cmd.clj:37)
at metabase.cmd$load_from_h2.invoke(cmd.clj:34)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.core$apply.invoke(core.clj:660)
at metabase.cmd$run_cmd$fn__73464.invoke(cmd.clj:168)
at metabase.cmd$run_cmd.invokeStatic(cmd.clj:168)
at metabase.cmd$run_cmd.invoke(cmd.clj:164)
at clojure.lang.Var.invoke(Var.java:388)
at metabase.core$run_cmd.invokeStatic(core.clj:150)
at metabase.core$run_cmd.invoke(core.clj:148)
at metabase.core$_main.invokeStatic(core.clj:172)
at metabase.core$_main.doInvoke(core.clj:167)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at metabase.core.main(Unknown Source)
Caused by: java.sql.SQLSyntaxErrorException: (conn=9718536) Data too long for column 'dataset_query' at row 1
at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.createException(ExceptionFactory.java:62)
at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.create(ExceptionFactory.java:153)
at org.mariadb.jdbc.MariaDbStatement.executeBatchExceptionEpilogue(MariaDbStatement.java:320)
... 50 more
Caused by: org.mariadb.jdbc.internal.util.exceptions.MariaDbSqlException: Data too long for column 'dataset_query' at row 1
at org.mariadb.jdbc.internal.util.exceptions.MariaDbSqlException.of(MariaDbSqlException.java:34)
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.exceptionWithQuery(AbstractQueryProtocol.java:194)
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.access$000(AbstractQueryProtocol.java:108)
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol$1.handleResultException(AbstractQueryProtocol.java:687)
at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:159)
at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:68)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: Data too long for column 'dataset_query' at row 1
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.readErrorPacket(AbstractQueryProtocol.java:1688)
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.readPacket(AbstractQueryProtocol.java:1550)
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.getResult(AbstractQueryProtocol.java:1513)
at org.mariadb.jdbc.internal.protocol.AsyncMultiRead.call(AsyncMultiRead.java:150)
... 5 more
Command failed with exception: (conn=9718536) Data too long for column 'dataset_query' at row 1

Changed the dataset_query column in the cards table to a LONGTEXT and then encountered a constraint violation because 1 of the user's email addresses was not unique.
Unfortunately don't have the stack trace for this one.

I changed the database collation to case-insensitive one and ran the script again. This time it was successful.

I then went into the database to change the duplicate user's email address to a dummy one and reverted the database schema changes. Done!

@thomasglas The migration problem only happens with MySQL as the application database:
https://github.com/metabase/metabase/issues/7006 - upvote by clicking :+1: on the first post

Hi @flamber Thanks for the quick reply.

The user is enabled on both Google and Metabase. Do you know how I can check the core_user table? I don’t see it anywhere in Metabase. I am an admin user so I should have the correct permissions.

@robrien

  1. Post “Diagnostic Info” from Admin > Troubleshooting.
  2. core_user is a table in the application database.

@flamber Please find below the diagnostic info. I see that the core_user table would need to be viewed using commands via the terminal. That’s something I would need to check with the team here. Please let me know if the diagnostic info is helpful.

{

“browser-info”: {
“language”: “en-US”,
“platform”: “Win32”,
“userAgent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36”,
“vendor”: “Google Inc.”
},
“system-info”: {
“file.encoding”: “UTF-8”,
“java.runtime.name”: “OpenJDK Runtime Environment”,
“java.runtime.version”: “11.0.7+10”,
“java.vendor”: “AdoptOpenJDK”,
“java.vendor.url”: “https://adoptopenjdk.net/”,
“java.version”: “11.0.7”,
“java.vm.name”: “OpenJDK 64-Bit Server VM”,
“java.vm.version”: “11.0.7+10”,
“os.name”: “Linux”,
“os.version”: “4.15.0-112-generic”,
“user.language”: “en”,
“user.timezone”: “GMT”
},
“metabase-info”: {
“databases”: [
“sqlserver”
],
“hosting-env”: “unknown”,
“application-database”: “postgres”,
“application-database-details”: {
“database”: {
“name”: “PostgreSQL”,
“version”: “11.6”
},
“jdbc-driver”: {
“name”: “PostgreSQL JDBC Driver”,
“version”: “42.2.8”
}
},
“run-mode”: “prod”,
“version”: {
“date”: “2021-01-20”,
“tag”: “v0.37.7”,
“branch”: “release-x.37.x”,
“hash”: “2b034aa”
},
“settings”: {
“report-timezone”: null
}
}
}