Cloudron Forum

Thank you for your answers.

@robi I use cloudron username. It would be strange to use email, as the expeted login is Mautic login which is basically the login managed by Cloudron, which is username-based, not email-based. No?

@girish I am not sure to understand your point. I think the the problem is not on n8n side but on the Mautic side. But if you mean that the problem might lie in the use of basic auth from n8n, I confirm that I do not use basic auth but OAuth2. Do you think the removal of basic auth in n8n would help in any way ? My current version of n8n is 0.166.0.

Hi all,

I would like to report what I experienced with Mautic API, at least when connecting via n8n. I think this is a bug (plus, maybe, an unexpected behaviour). Not able to investigate further because of my lack of experience.

Reproduce :

1. Perform a fresh Mautic install with Cloudron
2. Configure Mautic to use OAuth2 by creating API credentials
3. Try to connect to Mautic API via n8n by setting up a new account (classic configuration : callback URL reported into Mautic API configuration, Mautic URL, Mautic client ID & secret)
4. Under n8n a popup opens asking to log in Mautic (not really sure if it is a normal behaviour when you use OAuth2 instead of HTTP basic auth... anyway)
5. Enter any account credentials coming from Cloudron LDAP (important) and try to log in
6. Get a "Invalid credentials" error message

Already investigated :

• some report of this bug exist (StackOverflow, Mautic Community) and people say to clear cache - I tried it, didn't work
• some others report report an old bug (apparently fixed) making you need to activate "Basic HTTP Auth" even if you perform OAuth2, which is a nonsense - I tried it, juste to make sure, didn't work
• apparently, this bug seems impossible to reproduce impossible to reproduce when using credentials of a local Mautic account at step 5 - I then suspect a specific bug with Cloudron LDAP accounts

So, I don't need direct support as I apparently found a workaround. Anyway, I guess it would be useful to investigate further.

@imc67 said in Minio backup fails for no reason:

my backups are rsync and not tar

Thanks for the tip. I switched to rsync and I was full of hope. Unfortunately it also fails.

@girish I send you Minio full log by mail.

@girish

My Minio is self-hosted in a Docker on a Synology NAS which underlying filesystem is proprietary (btfrs). I already checked if there are any known issue reported with Minio. I will double check.

My Cloudron is hosted on Ubuntu / ext4.

@girish Done!

Thank you all.

@girish I increased the parameters step by step and tried to backup for each (until the max i.e. 16 go). I still have the same error message. Any help?

@girish

You can check this from the graphs maybe as to how much the app consumes? It's under System view.

Yes. As expected its huge as it is a Nextcloud. The entire app consumes 36 GB.

Yes, new in 5.4 and 5.5

And I think my problem appeared after 5.4 update. So basically I guess I need to increase memory limit? Up to... how much?

@girish I have no idea. I understand the backup fails when it comes to Nextcloud. So basically, the file is large.

Backup conf is on Minio.

Are those settings new ? I am pretty sure I have never seen them. I guess they have something to do with my problem...

Hello,

I have configured backups with Minio and it worked perfectly for weeks.

But it does no longer work. I think the problem started after an update, but I am not sure. As far as I understand from the logs (both from Cloudron and Minio sides) Cloudron tries to copy to Minio bucket a multipart archive and it fails. And Minio log says Cloudron tries to rename and/or copy a file that does not exist (yet, I guess).

Abstract from Cloudron log :

Unable to backup { BoxError: Error copying crsav_/snapshot/app_f0770611-2970-4e86-9047-0260e0297b79.tar.gz.enc (35961955060 bytes): XMLParserError XMLParserError: Unexpected close tag\nLine: 5\nColumn: 7\nChar: >' }

Abstract from Minio log :

Error: rename /data/.minio.sys/tmp/057fd8e5-234e-4e99-abe9-4ddb96796b34/e4b6158e-b4f5-4afc-8bb2-08e63228e618.2ff401ac-895f-43f9-aa2a-e40e9b862aef.9 /data/.minio.sys/multipart/caa122a8292342e6d4f7592bf3aed821c15f88ae471d458b70474d192b99be02/e4b6158e-b4f5-4afc-8bb2-08e63228e618/00009.0d55bc9f9c910f5b64049580ba387d34.1073741824: no such file or directory

       5: github.com/minio/minio@/cmd/fs-v1-helpers.go:397:cmd.fsSimpleRenameFile()

       4: github.com/minio/minio@/cmd/fs-v1-multipart.go:331:cmd.(*FSObjects).PutObjectPart()

       3: github.com/minio/minio@/cmd/fs-v1-multipart.go:259:cmd.(*FSObjects).CopyObjectPart()

       2: github.com/minio/minio@/cmd/object-handlers.go:1892:cmd.objectAPIHandlers.CopyObjectPartHandler()

       1: net/http/server.go:2007:http.HandlerFunc.ServeHTTP()

Thank you,
Thibaud

@girish Thank you very much for your answer. The endpoint of my Minio Server has definitely to be https: it is configured for https and it works from desktop Minio Client with https. Anyway, I tried with http and I get the same error.

Would it be possible to get more details on this error at this stage (e.g. via CLI or technical logs)? Because this error clearly seems to be the very end of a longer error stack trace.

Hi everyone,

I try to configure backups with Minio but unfortunately it won't work. I tried both tarball and rsync. My Minio Server works fine (tested with Minio Client from my laptop). I always obtain the same error message "Unexpected close tag Line: 5 Column: 7 Char: >".

I tried to check (Cloudron) logs to get more details but this event is not in the log, maybe because it's occurring during first configuration. Nothing in Minio Server logs.

Of course, I found this post which seems similar but it's not really the same and I only have one fresh Wordpress install in my Cloudron for the time being.

Any idea?

Thank you very much!