search

linuxserver / docker-papermerge

GNU General Public License v3.0
47 stars 13 forks source link

Error 500 when reaching WEB UI (latest) #27

Closed guim31 closed 3 years ago

guim31 commented 3 years ago

linuxserver.io

Expected Behavior

After login I should lan on the dashboard

Current Behavior

The login page shows well. When I try to login usin admin:admin, I get an ERROR 500 message. Tested with Brave browser and Firefox.

Environment

UNRAID server CPU architecture: x86_64 How docker service was installed: Here is my container setup (I leave it as the original template) https://i.imgur.com/WnQHVEg.png

Command used to create docker container (run/create/compose/screenshot)

Using Unraid' s docker manager

Docker logs

Here is the docker log :

https://pastebin.com/sBR3KBaF

yieldhog commented 3 years ago

I am having the same issue, installed on:

Synology, latest docker, default config


2021-02-27 00:00:39 | stdout | sqlite3.OperationalError: unable to open database file
-- | -- | --
2021-02-27 00:00:39 | stdout | conn = Database.connect(**conn_params)
2021-02-27 00:00:39 | stdout | File "/usr/local/lib/python3.8/dist-packages/django/db/backends/sqlite3/base.py", line 207, in get_new_connection
2021-02-27 00:00:39 | stdout | return func(*args, **kwargs)
2021-02-27 00:00:39 | stdout | File "/usr/local/lib/python3.8/dist-packages/django/utils/asyncio.py", line 26, in inner
2021-02-27 00:00:39 | stdout | self.connection = self.get_new_connection(conn_params)
2021-02-27 00:00:39 | stdout | File "/usr/local/lib/python3.8/dist-packages/django/db/backends/base/base.py", line 200, in connect
2021-02-27 00:00:39 | stdout | return func(*args, **kwargs)
2021-02-27 00:00:39 | stdout | File "/usr/local/lib/python3.8/dist-packages/django/utils/asyncio.py", line 26, in inner
2021-02-27 00:00:39 | stdout | self.connect()
2021-02-27 00:00:39 | stdout | File "/usr/local/lib/python3.8/dist-packages/django/db/backends/base/base.py", line 219, in ensure_connection
2021-02-27 00:00:39 | stdout | Traceback (most recent call last):
2021-02-27 00:00:39 | stdout | [2021-02-27 01:00:39,598: ERROR/ForkPoolWorker-2] Task papermerge.core.management.commands.worker.txt2db[90ccf32c-29be-421f-902a-c9fdf718207e] raised unexpected: OperationalError('unable to open database file')
2021-02-27 00:00:39 | stdout | [2021-02-27 01:00:39,593: DEBUG/ForkPoolWorker-2] Celery beat: txt2db
2021-02-27 00:00:39 | stdout | [2021-02-27 01:00:39,591: INFO/MainProcess] Received task: papermerge.core.management.commands.worker.txt2db[90ccf32c-29be-421f-902a-c9fdf718207e]
2021-02-27 00:00:39 | stdout | [2021-02-27 01:00:39,587: INFO/Beat] Scheduler: Sending due task txt2db (papermerge.core.management.commands.worker.txt2db)
2021-02-26 23:59:35 | stdout | django.db.utils.OperationalError: unable to open database file
Altomugriento commented 3 years ago

Fixed in version 2.0.0rc38.

sportsfan986 commented 3 years ago

RC38 (latest as of now) fixed the issue for me. It was something done on the papermerge side.

ciur commented 3 years ago

papermerge here :) The problem was caused by "inconsistent migrations order"

raise InconsistentMigrationHistory(
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration core.0033_auto_20201119_0032 is applied before its dependency core.0032_auto_20201118_1628 on database 'default'.

Problem was in application; had nothing to do with docker container. As @sportsfan986 and @Altomugriento said, it was indeed fixed in 2.0.0rc38. Issue can be closed.

Thank you guys for fantastic containerization, you are awesome !

tobbenb commented 3 years ago

Thank you for the kind words and confirmation that it was a bug in the application @ciur 🙂

yieldhog commented 3 years ago

I continue to have this error .. unable to connect to database -- 500 error. This is on a fresh installation.

MattFromTheFuture commented 3 years ago

I too am having the same issue on a fresh install. Using Unraid and this is first time trying to get this specific app setup. Let me know what I can do to provide useful information, the logs are hard for me to parse, but I think it has something to do with the initial database creation? I'm new to posting issues on github so hope I'm not posting too much logs...

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 50-config: executing...
Traceback (most recent call last):
File "./manage.py", line 24, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 330, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 368, in execute
self.check()
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 392, in check
all_issues = checks.run_checks(
File "/usr/local/lib/python3.8/dist-packages/django/core/checks/registry.py", line 70, in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
File "/usr/local/lib/python3.8/dist-packages/papermerge/core/checks.py", line 110, in binaries_check
binary = os.path.basename(binary_path)
File "/usr/lib/python3.8/posixpath.py", line 142, in basename
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType
Traceback (most recent call last):
File "./manage.py", line 24, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 330, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 371, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 85, in wrapped
res = handle_func(*args, **kwargs)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/commands/migrate.py", line 75, in handle
self.check(databases=[database])
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 392, in check
all_issues = checks.run_checks(
File "/usr/local/lib/python3.8/dist-packages/django/core/checks/registry.py", line 70, in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
File "/usr/local/lib/python3.8/dist-packages/papermerge/core/checks.py", line 110, in binaries_check
binary = os.path.basename(binary_path)
File "/usr/lib/python3.8/posixpath.py", line 142, in basename
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType

129 static files copied to '/app/papermerge/static'.
Traceback (most recent call last):
File "./manage.py", line 24, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 330, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 371, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.8/dist-packages/django/core/management/commands/check.py", line 63, in handle
self.check(
File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 392, in check
all_issues = checks.run_checks(
File "/usr/local/lib/python3.8/dist-packages/django/core/checks/registry.py", line 70, in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
File "/usr/local/lib/python3.8/dist-packages/papermerge/core/checks.py", line 110, in binaries_check
binary = os.path.basename(binary_path)
File "/usr/lib/python3.8/posixpath.py", line 142, in basename
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/sqlite3/base.py", line 413, in execute
return Database.Cursor.execute(self, query, params)
sqlite3.OperationalError: no such table: core_user
fazzer4x commented 3 years ago

I too face this issue. I tried a clean install, deleting all images, folders etc. Nothing. The following error message just loops forever. 

[uwsgi-daemons] respawning "/usr/bin/python3 ./manage.py worker" (uid: 1001 gid: 1001)

 Traceback (most recent call last):

   File "./manage.py", line 24, in <module>

     execute_from_command_line(sys.argv)

   File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 401, in execute_from_command_line

     utility.execute()

   File "/usr/local/lib/python3.8/dist-packages/django/core/management/__init__.py", line 395, in execute

     self.fetch_command(subcommand).run_from_argv(self.argv)

   File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 330, in run_from_argv

     self.execute(*args, **cmd_options)

   File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 368, in execute

     self.check()

   File "/usr/local/lib/python3.8/dist-packages/django/core/management/base.py", line 392, in check

     all_issues = checks.run_checks(

   File "/usr/local/lib/python3.8/dist-packages/django/core/checks/registry.py", line 70, in run_checks

     new_errors = check(app_configs=app_configs, databases=databases)

   File "/usr/local/lib/python3.8/dist-packages/papermerge/core/checks.py", line 110, in binaries_check

     binary = os.path.basename(binary_path)

   File "/usr/lib/python3.8/posixpath.py", line 142, in basename

     p = os.fspath(p)

 TypeError: expected str, bytes or os.PathLike object, not NoneType

 [uwsgi-daemons] throttling "/usr/bin/python3 ./manage.py worker" for 33 seconds
yieldhog commented 3 years ago

I have installed several times w/ different images, same looping error, nothing works. @ciur can you please reopen? Doesn't seem to be a closed issue.

j0nnymoe commented 3 years ago

@yieldhog Please open a new issue and provide all the information that's requested in our issue template so we can help accordingly.

dm7500 commented 3 years ago

Seeing a similar issue. Posted my own issue https://github.com/linuxserver/docker-papermerge/issues/33

J000K3R commented 3 years ago

have the same issue on unraid docker.

dehessijames commented 3 years ago

On my existing installation, adding BINARY_STAPLER = "/usr/local/bin/stapler" to papermerge.conf.py as described here #33 fixed the problem. On new installations it seems to be necessary to run the docker once so that the papermerge.conf.py is created and the mentioned line can be added.

cjax82 commented 3 years ago

This decided to show up today and have attempted all of the fixes. Did notice the line above is BINARY_STAPLER = "/usr/local/bin/stapler" is already in the papermerge.conf.py and it's still having this issue. Have removed/reload/restarted the container in its own stack a number of times with various browsers to no change Server 500 error....

File "/usr/local/lib/python3.8/dist-packages/django/db/backends/sqlite3/base.py", line 207, in get_new_connection conn = Database.connect(**conn_params) django.db.utils.OperationalError: unable to open database file

Not sure how to reset the SQLite tied to django or rest it as it's on a Syno DSM 7 NAS Docker. Please see attached initial startup script logs. _papermerge_logs.txt

yieldhog commented 3 years ago

I have also tried newer versions and continue to have this same error, even with 

BINARY_STAPLER = "/usr/local/bin/stapler"

Included in papermerge.conf.py, unfortunately have given up -- beyond my capabilities here.

reddevil156 commented 3 years ago

I tried today the official docker image on an ubuntu system. I used the commands from the wiki https://docs.papermerge.io/Installation/docker.html#official-image

After starting the image I got the same Server Error 500. I could fix the problem by logging in to both docker images (papermerge_app and papermerge_worker) and edit the papermerge.conf.py. The path of stapler can be checked with which stapler The result was: /opt/app/.venv/bin/stapler

So I added the following line to both config files: BINARY_STAPLER = "/opt/app/.venv/bin/stapler"

Restart both images and everything works fine.

AnonJervis commented 2 years ago

Yup, can confirmed. I've tried setting this up since June with multiple new installation on my synology and it will initially work when it started importing from watch folder, but then it'll also give me the Server Error (500) and the whole site is inaccessible.

BINARY_STAPLER = "/usr/local/bin/stapler" is also in my papermerge.conf.py file so i'm at a complete loss.

kachunkachunk commented 2 years ago

Re: sqlite3.OperationalError: unable to open database file on Synology DSM:

Sorry for the necromancy on a closed issue here. If needed, I can open a new one with this info.

Per the error reported above, it's a permissions issue for your container vs storage. While the container was able to create the database files just fine under the desired UID/GID, another service account probably doesn't have sufficient rights. Or it could be an issue related to Synology's ACLs.

From the container environment's perspective (docker exec -it <container> bash), you'll find that both /data and papermerge.db show d---------+ permissions. So, from within the container, I just changed the directory to 755 (chmod 755 /data and note that this is not recursive) and restarted the container, to see it start just fine afterwards, somewhat to my surprise, as I didn't touch the database file. You can also probably do this from outside the container. Files and directories all became drwxr-xr-x+ or 755 (with presumably the same extra ACL bits, if you note the +). I'd expect non-abc/UID/GID users to have issues here, since these permissions still don't permit writes, and I was able to create users/groups/folders and stuff just fine.

I don't really have much more of an explanation for this. The UID/GID stuff is (and always was) mapped to a valid user, and the directories mapped/overlaid should have the correct ownership and permissions from the get-go.

Another solution is probably to not go with an integrated Db, and push it over to a MariaDb server and database.