Posts made by ekevu123

@girish Hi, sorry, I wasn't clear, I sent the second message and wanted to indicate that I found the issue and resolved it. The volume wasn't mounted correctly in the fstab.

The issue is that the base volume where Nextcloud has all its data didn't mount after the restart.

I am getting an Internal Server Error on my Nextcloud instance.

Version: Nextcloud 25.0.2

Full error message when opening the domain:
Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

The app status in Cloudron is constantly "starting", before that I had "not responding". I tried restarting the app, that's why it changed.

The issue started occuring after a server restart via Cloudron.

The logs keep repeating this error message:

Could not get appdata folder for js

Not sure what to do with that?

@scooke That's a bit far-fetched. I am a happy customer of Cloudron and trust the support team providing clear evidence that nothing serious happened. Since everything is working fine again, there is not necessarily a need for me to work on this further as the problem has been solved. I was only bringing an issue to the attention of the support that looked suspicious and then we clarified it thanks to this forum.

Don't forget that all of this could still be a bug of some sort, so it has nothing to do with smearing Cloudron and I still feel it was the right thing to bring this forward. Also, it has nothing to do with not understanding with what happens on the server, I explained the chain of events clearly above what failed when and got resolved after which actions.

@subven "blocks the server" means in this case: I couldn't access any installed application nor the my subdomain to administrate cloudron. I could do it again after making the payment.

Good to hear that this might be a bug, not policy, then hopefully, the team will pick it up.

@murgero There was no need to get in touch with support, because it was obvious what needed to be done to solve the problem. It seems like I started using Cloudron exactly 365 days before the issue occured.
Also, exchanging the credit card details, paying for the subscription manually and then restarting the server did solve the problem. So, I do see a connection here, not a bug.

@BrutalBirdie I sent an e-mail, happy to investigate it if it wasn't intentionial. After all, I do understand that you would want to enforce clients to pay for using your services, I just suggested to do it less radically.

My company's credit card expired during the year and I didn't update the card details for the cloudron subscription.

Here is what could have happened:

• Cloudron sends me a friendly reminder before the payment is due
• I update the credit card details
• That's it
  (Actually, that's what most SaaS companies did throughout the year)

Here is what actually happened:

• Cloudron sends me an e-mail that the payment was unsuccessful
• Cloudron blocks the server running the license immediately including all 8 applications for our company
• I had to update it immediately literally sitting with my phone on the beach.

Now you can argue that I am supposed to make sure that the payment details for all subscriptions stay always up-to-date, but you could also argue that it wouldn't be a big deal for Cloudron to run a few more days for free (worst case) instead of blocking server access immediately.

Two more things if someone else comes into that situation:

• You have to restart the server after renewing the license
• For the time the server blocked Cloudron, it would run with maximum CPU usage, but would go back to normal when the issue is resolved.

Two things worked for me:

• occ encryption:decrypt-all (on one of the server) which safely decrypted all files and disabled encryption in a couple of minutes
• on another server, this command didn't decrypt all files but ran without errors, so I needed to come up with another way. So, I put all files and folders into one folder on my laptop, used occ encryption:disable to disable encryption and then created a copy on my laptop, waited for the copy of the folder to upload to the server, then I would delete the original (and rename the copy). Took some time, but it worked.

@nebulon It worked when I set both to maximum, many thanks!

@nebulon I only have the memory limit and the upload part size as options, nothing more when using tgz.

@BrutalBirdie I cannot do a new backup, I need to implement this first as the original cloudron installation broke. I tried to restart the import already several times.

My only other alternative is to reupload everything from my computer.

There can be a few large file names, but not many.

Thank you for pointing out the maintenance window, I didn't know that. But that is not yet, so it shouldn't have any impact.

I am wondering if I just see what will happen until tomorrow morning (maybe it will continue at some point) or if it makes sense to use rsync, but I am not sure if that works if I made the original backup in another format.

I tried it already several times and get stuck at different times.

@BrutalBirdie But wouldn't that only apply to future backups? Or can I try to reinstate this backup this way?

@nebulon Thank you, there was an error with Vultr, that's why it didn't work, but their support fixed it.

Cloudron Version 7.3.4
Backup configuration:

{
    "remotePath": "2022-12-14-230000-802/app_PATH_v4.16.0",
    "encrypted": false,
    "provider": "backblaze-b2",
    "format": "tgz",
    "memoryLimit": 2147483648,
    "schedulePattern": "00 00 1 * * *",
    "retentionPolicy": {
        "keepWithinSecs": 172800
    },
    "bucket": "my-cloudron",
    "prefix": "XX",
    "accessKeyId": "XYZ",
    "endpoint": "XXX.backblazeb2.com",
    "uploadPartSize": 134217728,
    "encryption": null
}

I restarted the backup but I get the same error, the speed drops to zero in the process.

Hi, I am importing a Nextcloud app backup in Cloudron and it repeats this message in the logs for quite some time already:

Dec 15 20:45:36 box:tasks update 473: {"percent":75,"message":"Downloading 2368M@0MBps"}

with just the time changing.

Is it normal that the percentage is not moving at all?

I am using a Vultr Block storage as a volume to host my Nextcloud data. Recently, I have increased the space in GB of the block storage, but this is not reflected in Cloudron. What am I missing?

What's the best way to turn off encryption for a Nextcloud instance that is already in use? I found different tutorials in the internet, so let's ask to be on the safe side. I have regular backups (thanks to Cloudron).

@jdaviescoates That sounds like a reasonable approach, I take that into consideration.

I am running Nextcloud 25.0.2 on Cloudron 7.3.4. Since the latest Nextcloud upgrade, I get this sync error on my laptop client:

Encryption not ready: multikeyencryption failed error:0480006C:PEM routines::no start line)

Does anyone have an idea how to solve this?

@girish Okay, that is super easy, thank you very much!

Is there an easy way to clone a Cloudron app?

I want to fork our Wordpress site into another Cloudron app on the same server to work on an update that shouldn't be released immediately.

I tried to use the backup configuration file to import a backup into the new app (which has a different domain name, of course). However, the app is not responding.

I am going to investigate the issue individually, but maybe there is a better way to achieve what I want to do?

@jdaviescoates Yes, the latest app update has resolved the issue!

Thank you for your help with this, though.

@nebulon said in Copy-pasting from editor disabled:

Thanks for the details reproduction steps, but I can't quite see this on my instances. Have you also tried to ask upstream if they maybe have some explanation on how this works or if there is some conscious restriction on the clipboard based on user permissions?

Yes, I got the above-mentioned code as a response, but I don't know exactly what to do with it.

@robi said in Copy-pasting from editor disabled:

That must be a Nextcloud office feature or security mechanism.

I know! But I am not getting behind how to fix this.

@nebulon Here is a step-by-step breakdown:

1. Open any office document in Nextcloud Office, the file format doesn't matter
2. Mark any text and copy it, either using right-click or Ctrl+C
3. Go to another Office program outside of Nextcloud
4. Insert it using either right click and paste or Ctrl+V

Expected behaviour:
The marked and copied text appears in the other office program.

Actual behaviour:
The pasted output is a message indicating that copy-pasting is disabled instead of the text.

    Copying from the document disabled

This affects apparently everyone except the admin or file owner (not sure which one is right). It can be reproduced by several users in different browsers and also by me if I use the Impersonate app of Nextcloud to impersonate another user.

I am quite certain that the solution shouldn't affect the user's clipboard, but probably this is a user rights issue somehow.

@ekevu123 I found this possible solution: https://github.com/nextcloud/richdocuments/issues/2496#issuecomment-1274881244

But maybe you know where this patch needs to be added?

@nebulon Yes, this one!
I didn't see any blocked request in the browser.

@nebulon I believe it's an issue with Collabora, but perhaps only within Nextcloud. But since I can replicate it when impersonating an affected user from my computer, it is unlikely to be specific to one user's configuration only.

@nebulon I am talking about any office documents using Collabora, specifically from Collabora to any other application.

I am quite sure that it's not a client-side or browser issue because it happens to 10 user accounts and I can reproduce the issue when I impersonate anyone else, whereas it works for me being the admin (or file owner, not sure yet what the reason is).

The document itself can be copied within Nextcloud without any problems, so this issue is related to Collabora.

@nebulon Yes, I tried to restart them and adapted the keys.
It's not actually a specific document, but the message appears when I try to connect Only Office in the Nextcloud settings.

@nebulon I updated Cloudron and Nextcloud now, but the issue remains - copy-pasting from Collabora is still disabled for anyone but me.

@nebulon Yes, I know, but it doesn't show any update. Perhaps because I am running Cloudron 7.3 in the instance with the newer Nextcloud version and 7.2 in the other, where the update is not shown?

Is 7.3.1 stable enough to use now? I have received the update notification in my Cloudron instances, but it still contains a warning that it is unstable, so I am hesitant on my two production instances.

@ekevu123 I could narrow the issue down a bit - it occured in a Cloudron running Nextcloud 24.04, whereas it did not in another Cloudron running Nextcloud 24.06.
Can I enforce that update somehow to see if this fixes it?

I am having issues with Collabora, so I am looking into OnlyOffice as the office app for Nextcloud. I have installed both on the same server in Cloudron, but I get this error message when trying to connect:

Error when trying to connect (Error occurred in the document service: Error while downloading the document file to be converted.) (version 7.1.1.23)

Note that I did change the secret key and put it into Nextcloud, but it is still not working.

Since a few days ago, copy-pasting from Collabora doesn't work for anyone but me as the admin/owner of the folder. When someone from the logged in users attempts it, the output simply says that copy-pasting is disabled instead of the copied output.
It works with sharing the file via an external link and then accessing it, making it most likely a problem with user rights. However, I cannot figure it out.

Does anyone know more?

@subven That makes sense, however, I do not have the storage space in that Cloudron instance to do that with a second app, so I'll probably need to delete it and set it up again anyway then. But then re-implementing the backup from scratch might be even more helpful after I will have deleted it already.

@subven I do not have all the options you have here, but this is my output:

ls -la
total 12
drwxr-xr-x 3 yellowtent yellowtent 4096 Oct  3 09:41 .
drwxr-xr-x 3 yellowtent yellowtent 4096 Jun 26 11:40 ..
drwxrwx--- 9 www-data   www-data   4096 Sep 11 14:46 data

I cannot reinstall the backup in the same instance because I ran out of space in the disk. Moving the data directory failed, so I cannot revert it either.

My best alternative is to delete the app completely and then set it up again, either through backup or generally new, if I cannot solve this problem here. I was hoping to get access, though, so that I can still make the necessary changes.

@subven I tried to move the data directory in the storage submenu of the Nextcloud application.

I tried to move my Nextcloud app data to a block storage volume because I ran out of space, however, that failed.

Now I keep getting this error inside the application: Error : Addons Error - Error setting up postgresql. Status code: 500 message: connect ECONNREFUSED 127.0.0.1:5432

I cannot even import the last backup due to the same error.

How can I get access again?

I am using Vultr and Host Europe with Backblaze and Digital Ocean Spaces as Backups. So far, good experience with all of these providers. I'd give an edge to Vultr, though, because of the intuitive user interface and the multiple hosting options. I might exchange Backblaze for a cheaper option in the long run.

@subven I agree with that, we are using Postmark, it's $10 per month only for a normal volume and really easy to set up. The deliverability has increased compared to other solutions like a mail package with even an established company in the market.

@nebulon I can't share the original document publicly, unfortunately, but the problem has disappeared after having raised the PHP Memory Limit in Nextcloud from 512 MB to 2 GB.

@nebulon It is happening also with similarly big files (as in many pages, not big file size). I don't think it's necessarily a Cloudron issue, but it would still be great to understand if there are ways how this could be resolved.

@nebulon I just looked at the top command inside the Collabora app in Cloudron and never got the processor over 10% usage when scrolling through the document in different browsers. Same goes for the Nextcloud app, but since this is a rendering issue in Collabora, I wouldn't expect Nextcloud to react strangely anyway.

The file is 297KB with only a few small screenshots.

I can try re-setting up Collabora, but I didn't change anything from the standard configuration anyway, except giving it more resources in the Cloudron admin dashboard.

I have a dedicated server running Cloudron and Nextcloud and Collabora as separate applications on the same server.

When I am trying to open a long file with pictures, it takes endless time to open and I somehow suspect it's the editor's fault because of what I found in the logs during the file loading process:

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297249 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:3072:122880:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297361 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:12288:122880:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297370 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:0:125952:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297376 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:3072:125952:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297382 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:6144:125952:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297388 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:9216:125952:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297393 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:12288:125952:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297399 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:0:129024:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297404 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:3072:129024:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297409 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:6144:129024:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297414 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:9216:129024:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297419 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:12288:129024:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297425 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:0:132096:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297430 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:3072:132096:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297436 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:6144:132096:3072:3072:0 was dropped because of time out (5619ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297441 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:9216:132096:3072:3072:0 was dropped because of time out (5618ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

Jul 27 17:58:03 wsd-00014-34881 2022-07-27 15:58:03.297446 +0000 [ docbroker_611 ] WRN ToClient-666f: Tracker tileID 0:12288:132096:3072:3072:0 was dropped because of time out (5618ms). Tileprocessed message did not arrive in time.| wsd/ClientSession.cpp:2000

However, I don't know what to do with that. Can someone help?

@nebulon I am having the same issue. So, no quick solution in sight before the next release?

@chminc Indeed, I looked into this quite recently myself for our setup and came to very similar conclusions. It's not advised to use object storage. We will move to volume storage in case the space on the server won't be enough - it is not that much more expensive. But I have made really good experience with the Cloudron backup function, it restored everything completely error-free. And you can store the backup on object storage. Using encryption is not a problem at all.

@chminc Can't you use the Cloudron backup function to store a backup with an external provider, implement it in Cloudron on server B if you have to, and then do the same the other way round?
Backblaze or Digital Ocean Spaces worked well for us in similar cases.

@humptydumpty Thank you, that has actually worked!

I have moved a cloudron installation to a new server yesterday. The new server had Ubuntu 22.04 installed, the old one Ubuntu 20.04 (the Cloudron version was the same though). I used the backup and restore function.

One thing is not working: I have an e-mail address running and I cannot connect to it using two e-mail clients I have tried, Missive and Thunderbird. The error message says that it is an issue with the ssl certificate for this address.

I tried already the option "renew all certificates" in the cloudron dashboard, it ran, but it did not solve the problem.

This is what the logs say:
2022-06-29T14:02:08.065Z box:tasks update 1533: {"percent":92,"message":"Ensuring certs of email.thrived.app"}
2022-06-29T14:02:08.068Z box:reverseproxy ensureCertificate: email.thrived.app certificate already exists at /home/yellowtent/platformdata/nginx/cert/email.thrived.app.key
2022-06-29T14:02:08.074Z box:reverseproxy expiryDate: /home/yellowtent/platformdata/nginx/cert/email.thrived.app.cert notAfter=Aug 13 23:00:45 2022 GMT daysLeft=45.37403849537037
2022-06-29T14:02:08.079Z box:reverseproxy providerMatchesSync: /home/yellowtent/platformdata/nginx/cert/email.thrived.app.cert subject=CN = email.thrived.app domain=email.thrived.app issuer=C = US, O = Let's Encrypt, CN = R3 wildcard=false/false prod=true/true issuerMismatch=false wildcardMismatch=false match=true

I tried to delete the mentioned file in the terminal, hoping that it would be then regenerated, but I am still getting the above-mentioned error message.

How can I solve the issue?

@jdaviescoates This is an idea I have quickly considered as well but one reason why I want to move this installation to Cloudron so desperately is that I want to have less work with it, not more

We will probably need to live with the fact that we will need to re-share all information again and simply do the move using one of the manual ways (e.g. user migration plugin). That will create chaos for a day or two, but at least then we will have a more stable installation.

I got the user migration plugin to work (the process was terminated because the server didn't have enough resources), but I haven't attempted the migration yet because I cannot solve another problem:

All information which file is shared with whom would be completely lost and there doesn't seem to be a way to preserve it because the information is being stored in the database.

And the problem with this (https://github.com/nextcloud-snap/nextcloud-snap/wiki/Migrating-from-nextcloud-snap-to-Nextcloud-server) is that Cloudron uses PostgreSQL and not MySQL.

The only solution I have now is to manually go through everyone's account on both instances and see if I can share every user's file manually. That will mean a few hours of boring, manual work, unless someone has a better idea?

@humptydumpty I have read studies detailing this question a bit more. In total, DeepL is much better than Google Translate except for Russian (no experience with the new Asian languages yet). There are some commercial engines that work better for certain topics, but you would only want to look into this if you work in the translation industry. So, you can safely rely on it.

The user migration plugin just provides me with an empty archive file, so this doesn't seem to be an option. I will try the other mentioned option then next time.