Error occurs when exporting account #969

New Issue

asraelvudogel · 2021-09-06T17:29:09Z

asraelvudogel commented

2021-09-06 17:29:09 +00:00

Hi,

during the export process of my account I get an error in the logs:

ERROR ▶ [EVENTS] 123 Error occurred, retrying: mkdir /app/vikunja//files/user-export-tmp/: permission denied, elapsed_time=59.995041ms, retry_no=1, max_retries=5, wait_time=58.368929ms

And the whole process is aborted after 5 attemps.

My idea is, that the error occurs cause of the double slash after "vikunja" ?!

Hi, during the export process of my account I get an error in the logs: ERROR ▶ [EVENTS] 123 Error occurred, retrying: mkdir /app/vikunja//files/user-export-tmp/: permission denied, elapsed_time=59.995041ms, retry_no=1, max_retries=5, wait_time=58.368929ms And the whole process is aborted after 5 attemps. My idea is, that the error occurs cause of the double slash after "vikunja" ?!

konrad commented

2021-09-06 19:02:07 +00:00

Have you checked the user running Vikunja has write access to the folder at /app/vikunja/files/? To see if it's a problem with the slash, try removing it from the rootpath in the config.

Have you checked the user running Vikunja has write access to the folder at `/app/vikunja/files/`? To see if it's a problem with the slash, try removing it from the rootpath in the config.

konrad added the

question

label 2021-09-06 19:02:20 +00:00

asraelvudogel commented

2021-09-06 19:10:07 +00:00

Hi,

I'm running vikunja on docker and deployed it with the docker-compose files from your documentation. So I don't changed any configs.

After running the api-container as root , the export was generated, but left in the folder without file extension and without any notice in the frontend or in my mailfile.
So after adding a .zip, I could access the files inside and reimport them without an error.

Hi, I'm running vikunja on docker and deployed it with the docker-compose files from your documentation. So I don't changed any configs. After running the api-container as root , the export was generated, but left in the folder without file extension and without any notice in the frontend or in my mailfile. So after adding a .zip, I could access the files inside and reimport them without an error.

konrad commented

2021-09-06 19:20:49 +00:00

And you properly configured the mail connection?

Anything else in the logs?

And you properly configured the mail connection? Anything else in the logs?

asraelvudogel commented

2021-09-06 20:04:19 +00:00

The mail connection is set up with following environment variables in the api-container-section of the docker-compose-file but I don-t get any mails despite that the credentials are correct:

VIKUNJA_MAILER_ENABLED: 1
VIKUNJA_MAILER_HOST: [HOST]
VIKUNJA_MAILER_PORT: [PORT]
VIKUNJA_MAILER_USERNAME: [USER]
VIKUNJA_MAILER_PASSWORD: [PASS]
VIKUNJA_MAILER_FORCESSL: 1

But there is nothing else in the logs, just a lot of lines like this:

2021-09-06T19:59:42.652036864Z: WEB ▶ [IP of my router] GET 200 /api/v1/notifications?page=1 14.283743ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

The mail connection is set up with following environment variables in the api-container-section of the docker-compose-file but I don-t get any mails despite that the credentials are correct: VIKUNJA_MAILER_ENABLED: 1 VIKUNJA_MAILER_HOST: [HOST] VIKUNJA_MAILER_PORT: [PORT] VIKUNJA_MAILER_USERNAME: [USER] VIKUNJA_MAILER_PASSWORD: [PASS] VIKUNJA_MAILER_FORCESSL: 1 But there is nothing else in the logs, just a lot of lines like this: 2021-09-06T19:59:42.652036864Z: WEB ▶ [IP of my router] GET 200 /api/v1/notifications?page=1 14.283743ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

konrad commented

2021-09-06 20:16:23 +00:00

I've noticed a potential cause of the issue:

api_1       | 2021-09-06T20:07:01.890506981Z: ERROR	▶ [EVENTS] d058 Error occurred, retrying: 1 error occurred:
api_1       | 	* panic occurred: "invalid memory address or nil pointer dereference", stacktrace: 
api_1       | goroutine 355 [running]:
api_1       | runtime/debug.Stack(0xc0008372a0, 0x12036c0, 0x1d33270)
api_1       | 	/usr/local/go/src/runtime/debug/stack.go:24 +0x9f
api_1       | github.com/ThreeDotsLabs/watermill/message/router/middleware.Recoverer.func1.1(0xc000837c58)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/recoverer.go:27 +0x76
api_1       | panic(0x12036c0, 0x1d33270)
api_1       | 	/usr/local/go/src/runtime/panic.go:965 +0x1b9
api_1       | code.vikunja.io/api/pkg/models.exportListsAndTasks(0xc00042b790, 0xc00017cd80, 0xc000837aa0, 0xc0005f1000, 0xc000944d30)
api_1       | 	/go/src/code.vikunja.io/api/pkg/models/export.go:188 +0xb18
api_1       | code.vikunja.io/api/pkg/models.ExportUserData(0xc00042b790, 0xc00017cd80, 0x0, 0x0)
api_1       | 	/go/src/code.vikunja.io/api/pkg/models/export.go:60 +0x488
api_1       | code.vikunja.io/api/pkg/models.(*HandleUserDataExport).Handle(0x1e19630, 0xc00082c4e0, 0x0, 0x0)
api_1       | 	/go/src/code.vikunja.io/api/pkg/models/listeners.go:593 +0x1ef
api_1       | github.com/ThreeDotsLabs/watermill/message.(*Router).AddNoPublisherHandler.func1(0xc00082c4e0, 0xc000837cec, 0x2, 0x2, 0xc0006a20a0, 0xc000734ea0)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:284 +0x2f
api_1       | github.com/ThreeDotsLabs/watermill/message/router/middleware.Recoverer.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/recoverer.go:32 +0x71
api_1       | github.com/ThreeDotsLabs/watermill/message/router/middleware.Retry.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/retry.go:71 +0x2f3
api_1       | github.com/ThreeDotsLabs/watermill/message/router/middleware.poisonQueue.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/poison.go:99 +0xed
api_1       | github.com/ThreeDotsLabs/watermill/components/metrics.HandlerPrometheusMetricsMiddleware.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/components/metrics/handler.go:57 +0x1ec
api_1       | github.com/ThreeDotsLabs/watermill/message.(*handler).handleMessage(0xc0003ff540, 0xc00082c4e0, 0xc0002868e8)
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:601 +0x17b
api_1       | created by github.com/ThreeDotsLabs/watermill/message.(*handler).run
api_1       | 	/go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:472 +0x2f1

Put up a patch which should prevent this and adds more logging for those cases in cc1bb3083f. Could you enable debug logging and try again with the next unstable version? It should be ready and released in ~30 min.

I've noticed a potential cause of the issue: ``` api_1 | 2021-09-06T20:07:01.890506981Z: ERROR ▶ [EVENTS] d058 Error occurred, retrying: 1 error occurred: api_1 | * panic occurred: "invalid memory address or nil pointer dereference", stacktrace: api_1 | goroutine 355 [running]: api_1 | runtime/debug.Stack(0xc0008372a0, 0x12036c0, 0x1d33270) api_1 | /usr/local/go/src/runtime/debug/stack.go:24 +0x9f api_1 | github.com/ThreeDotsLabs/watermill/message/router/middleware.Recoverer.func1.1(0xc000837c58) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/recoverer.go:27 +0x76 api_1 | panic(0x12036c0, 0x1d33270) api_1 | /usr/local/go/src/runtime/panic.go:965 +0x1b9 api_1 | code.vikunja.io/api/pkg/models.exportListsAndTasks(0xc00042b790, 0xc00017cd80, 0xc000837aa0, 0xc0005f1000, 0xc000944d30) api_1 | /go/src/code.vikunja.io/api/pkg/models/export.go:188 +0xb18 api_1 | code.vikunja.io/api/pkg/models.ExportUserData(0xc00042b790, 0xc00017cd80, 0x0, 0x0) api_1 | /go/src/code.vikunja.io/api/pkg/models/export.go:60 +0x488 api_1 | code.vikunja.io/api/pkg/models.(*HandleUserDataExport).Handle(0x1e19630, 0xc00082c4e0, 0x0, 0x0) api_1 | /go/src/code.vikunja.io/api/pkg/models/listeners.go:593 +0x1ef api_1 | github.com/ThreeDotsLabs/watermill/message.(*Router).AddNoPublisherHandler.func1(0xc00082c4e0, 0xc000837cec, 0x2, 0x2, 0xc0006a20a0, 0xc000734ea0) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:284 +0x2f api_1 | github.com/ThreeDotsLabs/watermill/message/router/middleware.Recoverer.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/recoverer.go:32 +0x71 api_1 | github.com/ThreeDotsLabs/watermill/message/router/middleware.Retry.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/retry.go:71 +0x2f3 api_1 | github.com/ThreeDotsLabs/watermill/message/router/middleware.poisonQueue.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router/middleware/poison.go:99 +0xed api_1 | github.com/ThreeDotsLabs/watermill/components/metrics.HandlerPrometheusMetricsMiddleware.Middleware.func1(0xc00082c4e0, 0x0, 0x0, 0x0, 0x0, 0x0) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/components/metrics/handler.go:57 +0x1ec api_1 | github.com/ThreeDotsLabs/watermill/message.(*handler).handleMessage(0xc0003ff540, 0xc00082c4e0, 0xc0002868e8) api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:601 +0x17b api_1 | created by github.com/ThreeDotsLabs/watermill/message.(*handler).run api_1 | /go/pkg/mod/github.com/!three!dots!labs/watermill@v1.1.1/message/router.go:472 +0x2f1 ``` Put up a patch which should prevent this and adds more logging for those cases in cc1bb3083f1957f0b45dd6e5131a8c0a837919b4. Could you enable debug logging and try again with the next unstable version? It should be ready and released in ~30 min.

asraelvudogel commented

2021-09-06 20:31:42 +00:00

Yes, of course.

In the meantime I set the loglevel to debug and get the confirm, the the export is created:

2021-09-06T20:21:47.534433748Z: DEBUG ▶ models/Handle 135 Starting to export user data for user 1...,
2021-09-06T20:21:47.627553862Z: DEBUG ▶ models/Handle 200 Done exporting user data for user 1...

The short time between start and finish is okay, because I don't have a lot of data in there.

Yes, of course. In the meantime I set the loglevel to debug and get the confirm, the the export is created: 2021-09-06T20:21:47.534433748Z: DEBUG ▶ models/Handle 135 Starting to export user data for user 1..., 2021-09-06T20:21:47.627553862Z: DEBUG ▶ models/Handle 200 Done exporting user data for user 1... The short time between start and finish is okay, because I don't have a lot of data in there.

asraelvudogel commented

2021-09-06 21:17:26 +00:00

I'm finaly getting an email from my vikunja instance, but the link is not working.
If I copy the url to my browser, it works.

I'm finaly getting an email from my vikunja instance, but the link is not working. If I copy the url to my browser, it works. ![grafik](/attachments/17fd393b-a7ea-428b-ad21-98908692b56a)

grafik.png

11 KiB

konrad commented

2021-09-07 05:21:34 +00:00

What is the link? Have you configured the frontend URL in the api?