Cloudron Forum

@LoudLemur said: @jdaviescoates RustFS is available in unstable now. Would that suit? I think someone has packaged Garage too. I don't know if either would suit, but hopefully. A Cloudron S3 addon would be great. In the interim, I wonder if it might be possible to package an app that requires adding some S3 credentials as part of the initial configuration?

Hello @mathieuepitech Okay, so the network issue is resolved by the applied patch. When you configure your docker registry in the Cloudron Dashboard, is there any error when saving?

Hello @jlx89 As you have already posted in https://forum.cloudron.io/topic/15385/twenty-crm-update-on-cloudron-fails-database-schema-mismatch-missing-column please read this topic to understand the issue and the solution.

Hello @davejgreen @davejgreen said: I tried the rsync attempt last week, then I erased everything on the new server to try again. Ah! Thanks for the clarification. I indeed did not understand you correctly. @davejgreen said: Then when I start the restore from there, doesn't this happen on the new server? https://docs.cloudron.io/backups/#dry-run-restore Dry run skips DNS updates. The new server won't be publicly accessible - you access it using /etc/hosts entries on your local machine. Dry run will not change any DNS records. This also means, as soon as you hit the restore with dry run, when a redirect happens to your restored domain, you DNS will resolve to your production server. This is why you need to update your local device /etc/hosts to prevent this. If one does not do that, you can have a mixed view of the dashboard of cached content, the old server serving stuff and the new system serving stuff. @davejgreen said: The first error message started with "Access denied." which makes me think the problem might be related to file and folder ownership and/or permissions, as I am often confused by these. This could be an issue. With this partial mount that is failing, can you review the access to that mounted NFS?

Hello @ntnsndr and @valexico That two times a Hostinger set up is having the same issue is not a coincidence. Still, I am not sure what is going on. The file in question exists. So why does the docker daemon suddenly act in this way.

@filter i have submitted a PR here - https://github.com/knadh/listmonk/pull/3012

@nebulon Thank you! I think I have something working in n8b, but hit a snag when trying to auth and I think I can make it work. Once the App Password portion is fixed in 9.2, if this works using n8n, I'll post the n8n template to accomplish this.

@girish I would be surprised if they were to backtrack that move. The developers were always one step towards that direction, they simply used AI scanners as an excuse to close the code earlier (which was arguably pretty much already closed). It's only a matter of time before the "new" https://github.com/calcom/cal.diy repo gets archived.

The new package update is already in our release pipeline yes

@james Thanks for looking into this - this is what I feared. As far as I can tell, Docmost has not changed its licensing model in a recent past or at least not since becoming an app available on Cloudron. Additionally, I have some vague recollection of similar situations with other apps on Cloudron (a quick search reveals apps like Baserow and Mattermost) For now we are looking at trialing Docmost enterprise with the ultimate view to possibly adopt it for all the benefit and additional features it provides. For example, things like OIDC is locked behind the (trial) license and it is not quite clear if/how we would connect it with Cloudron as an OIDC provider for now. How has Cloudron approached situation such as this one (if any)? was it through direct contact with the dev-team? If so, would it help if I attempt to put you in relation with a relevant contact? would the best way be for the docmost dev(s) to contact support@cloudron.io directly? I suspect that building the Enterprise version of Docmost would not get away from needing a valid license. Also, I do not think that pulling a partly private app image conflicts with having an open source cloudron app package residing on cloudron gitlab does it? Possibly it just requires an agreement and permissions between Cloudron and Docmost.