Cloudron Forum

I have the same issue, so let me provide a use case why moving the app's data directory is not such a great usecase. Here is a story to illustrate:

• You are an event photographer. Let's assume you are publishing pictures en-masse using an image editing software like Lightroom
• Lightroom workflow allows pictures to be exported on a NFS/CIFS/SMB share
• You attach the NFS/CIFS/SMB share to the app as a mount
• Immich picks up the images just fine from the external directory (mount)
• The RAW images (masters) are stored separately on a PC or a NAS. They don't need to be on Immich. They are the backup or backed up elsewhere essentially
• You are collecting pictures from other participants from an event and since they are likely not advanced users they will use the upload button
• The upload button uploads images to the app's storage space rather than the mount
• You want import newly uploaded pictures from other people to your Lightroom database and the best method is via a separate NFS/CIFS/SMB share for uploads
• Moving the user uploaded pictures from the app's storage to the mount is not possible from within the app
• Moving the user uploaded pictures from the app's Cloudron file manager to the mount is not practical. Also it might break things.

My point:

• You can't publish pictures and import new pictures easily directly from&to lightroom if everything is in the app's native storage.
• To upload you need to use the upload button or API.
• If you were to choose the launch Immich's API from within Lightroom - after export you can launch a custom script under the "post processing" section, but good luck passing the correct parameters. It will be a nightmare to manage and update.
• Using nextcloud is cumbersome for most people. They need simplicity. A dedicated solution. Also Immich has better sharing features and presentation.

Complications aside, since the metadata could be baked into the pictures via lightroom or phone the Immich Metadata DB is not that precious. It's just an outlet. Exposing the .env could cause severe complications, but the risk is mitigated by other methods already. There should be an option for this with the neccessary disclaimers. Image Pros would appreciate.

For those who still struggle with the SQL method:
Open up the terminal and just paste in this command to disable Sogo 2FA for a specific mailbox / user

sogo-tool user-preferences set defaults your@email.com SOGoTOTPEnabled '{"SOGoTOTPEnabled":0}'

@girish this single line of code could be easily added to the documentation: https://docs.cloudron.io/apps/sogo/
There is nothing there regarding 2FA reset.

"sogo-tool" is a CLI tool. Comes built in with the deployed image.
Source for the solution: https://github.com/mailcow/mailcow-dockerized/issues/4490#issuecomment-1052121610

It worked! Thanks!

Hi Staff,

Currently, the mailbox ingress access is tied to the cloudron password with the IMAP implementation if I understood the documentation correctly.

I am wondering if there is any way to create an app password for emailing, so the email clients IMAP settings don't break after a cloudron user account password reset. It's a hassle to chase down every client on every device and modify the IMAP one by one. Google calls its implementation app password, and it provides a persistent solution for this use case.

Thanks in advance.

RESOLVED:
It's likely that cloudflare was having some internal issue, but upon checking https://www.cloudflarestatus.com/ I was left more confused is there was any incident on their end in my region. It's buried under scheduled maintanaces and other stuff.

I still not sure if this was the correct resolution, but it started working after executing these steps.

sudo apt-get install -y systemd
sudo nano /etc/systemd/resolved.conf

Added the DNS of Cloudflare and google

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1
#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111
#cloudflare-d># Google:     8.8.8.8
#dns.google 8.8.4.4
#dns.google 2001:4860:4860::8888
#dns.google 2001:4860:4860::8>
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112
#dns.quad9.net 2620:fe::fe
#dns.quad9.net 2620:fe::>
DNS=1.1.1.1 8.8.8.8

sudo systemd-resolve --flush-caches
# didn't work
systemd-resolve --status 
# wasn't even running. So maybe the config change was irrelevant

Reboot and started working... and I am not sure how this is possible...

Anyway that for the help. This issue was plaguing me for a few days.

Yes, so SSH from cloudron instance gives me

host -t NS mydomain.com
mydomain.com name server kristin.ns.cloudflare.com.
mydomain.com name server titan.ns.cloudflare.com.

Upon doing dig on my subdomain after they are live in the registrar for a day.

dig +trace subdomain.mydomain.com

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> +trace subdomain.mydomain.com
;; global options: +cmd
.                       86399   IN      NS      a.root-servers.net.
.                       86399   IN      NS      b.root-servers.net.
.                       86399   IN      NS      c.root-servers.net.
.                       86399   IN      NS      d.root-servers.net.
.                       86399   IN      NS      e.root-servers.net.
.                       86399   IN      NS      f.root-servers.net.
.                       86399   IN      NS      g.root-servers.net.
.                       86399   IN      NS      h.root-servers.net.
.                       86399   IN      NS      i.root-servers.net.
.                       86399   IN      NS      j.root-servers.net.
.                       86399   IN      NS      k.root-servers.net.
.                       86399   IN      NS      l.root-servers.net.
.                       86399   IN      NS      m.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 51 ms

;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for subdomain.mydomain.com failed: network unreachable.
;; no servers could be reached

;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for subdomain.mydomain.com failed: network unreachable.
;; no servers could be reached

;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for subdomain.mydomain.com failed: network unreachable.
;; Received 45 bytes from 192.112.36.4#53(g.root-servers.net) in 27 ms

or

nslookup -type=NS subdomain.mydomain.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
*** Can't find subdomain.mydomain.com: No answer

Authoritative answers can be found from:
mydomain.com
        origin = kristin.ns.cloudflare.com

Further updates:

• After restarting the service a few times it managed to propagate. This is unusual...
• However even after proper propagation when I make even a simple adjustment for the service like enabling a port for the container over the GUI, the container restarts and "Will retry: queryNs ESERVFAIL" comes back again, and I have to restart the container a few more times until the comes back online properly. This is also very unusal.

Additional problems caused by the DNS propagation issue:

• The built-in mailbox DNS entries also got broken:

MX record 
- Hostname: @
- Record type: MX
- Expected value: 10 mail.mydomain.com.
- Current value: [not set]
DKIM record 
- Hostname: cloudron._domainkey
- Record type: TXT
- Expected value: v=DKIM1; t=s; p=[dkim_key_goes here]
- Current value: [not set]
SPF record 
- Hostname: @
- Record type: TXT
- Expected value: v=spf1 a:mail.mydomain.com ~all
- Current value: [not set]
DMARC record 
- Hostname: _dmarc
- Record type: TXT
- Expected value: v=DMARC1; p=reject; pct=100
- Current value: [not set]
PTR record 
- The PTR record is set by your VPS provider and not by your DNS provider. 
- Hostname: 45.56.67.78 {not my real IP}
- Record type: PTR
- Expected value: mail.mydomain.com
- Current value: [not set]

It was not an issue before. I've checked and in the registrar they are there still. But somehow they don't propagate.

Dear Support,

I've moved to a new networking setup, and installing new items from appstore seems to be not working anymore.
Logs state something like

box:dns/waitfordns Attempt 1 failed. Will retry: queryNs ESERVFAIL mydomain.com
box:dns/waitfordns Attempt 2 failed. Will retry: queryNs ESERVFAIL mydomain.com

• The app has been created via cloudflare DNS API
• I see the new A record created in the registrar.
• The DNS is pointing to the same IP as the dashboard (no cloudflare proxy).
• The ports are correctly forwarded and other installed apps are working.
• Only the new application install seems to be affected.

Can you advise?

Dear Support,

Recently I am looking to create a shared calendar resource in SOGo. The idea would be that customers (or 3rd parties who don't possess cloudron mailbox in my infra) could get authenticated access and create calendar events over outlook or some other mail client via .ics or some other method.

What works:

• Currently the Outlook calendar correctly authenticates and pulls the events first time.
• Modifying it in SOGo updates the calendar on the client app. Wonderful!

What doesn't work:

• Modifing the calendar on the client side -like moving an event-, doesn't get applied in SOGo even after hitting send/receive. It stays offline.
• I am not sure if the sharing permissions apply correctly.

I would like to request ways to test out my sharing permissions. Can you recommend another offline client which proven to working?

SOLVED:
I wasn't using my Cloudron instance as mail server. I have some ISP issues with inbound email so I try to avoid cloudron mailbox for now. The good news is that for the SoGO login doesn't need a fully working mailbox just an existing one. The domain mentioned in the manual is the dns domain(!!)

Anyways the steps which fixed the issue:

For this example let's assume your domain is hostedservice.page and we will create a mailbox james@hostedservice.page

• Go to Cloudron Dashboard
• Under profile select "Email"
• Edit the domain of your choice which in our case is hostedservice.page, where you want to host the mailbox. You'll find it under Domains → Domain → Actions → Edit
• Under Email configuration hostedservice.page you'll find Mailboxes
• Click on Add and select a name like "james" and assign a cloudron "owner" as the Cloudron dashboard user account who will own the mailbox.
• Click on the created mailbox and you will see something like james@hostedservice.page
• Go back to SoGO and use the mailbox username james@hostedservice.page and the cloudron user password
• You are in. That's all.

Thanks for the help!

Hi! I am looking for some clarification related to the documentation found in https://docs.cloudron.io/apps/sogo/#login

The manual states: "SOGo only works with mailbox accounts on the Cloudron. Login using the full email address including the domain as the username."

I tried using the email address defined in Cloudron Dashboard → Profile → Primary address and the associated password which you can access the dashboard with.
I also tried to create separate users to test out what the issue might be, but no dice.

I am not sure how to "include the domain as username" Can you give me an example for the full process? I must be missing something.

That makes sense, and I support the idea. The error message points the blame to the API and not the DNS. Modifying the error message to check the DNS first definitely saves time on the troubleshooting end and on yours.

Even if it's the exception the it's worth considering how much time it takes to check for each step during the process. Anyways thanks for the help. You can close this thread

@girish Thank you for checking. I will look into other options in cloudron to do this.

SOLVED: Thank you for the suggestions. The api.cloudron.io might have been down temporarily.

• I ran host api.cloudron.io and it resolved to an IP address
• I found it strange, so I opened the app store and indeed everything was loading.
• Then I tried the recovery again to a stable version. It connected to the API to pull the image.
• After recovery the app was non responsive. It asked me to follow https://docs.cloudron.io/troubleshooting/#unresponsive-app
• I went into recovery mode, but couldn't find the correct script like "start.sh" to restart it.
• Without doing anything I disabled recovery mode and restarted the app. Opened to logs and it showed, it started reponding.
• It's working fine now.

I am bit surprised and concerned that the API connection has such a strong impact on recovery. If the API is not reachable then the correct image won't re-download. Bringing recovery to a stall. I am testing currently, but in production this can be a blocker. Is there a way to preload the image on Cloudron instance in case of emergency?

Dear Support, I got this error message after rebooting the app. Recovering the unsuccessful from stable backup

• It's not possible to reboot from dashboard or put it into recovery mode
• Terminal for the app doesn't open (file explorer does)
• Uninstalling the app is not possible. **Error message: Cloudron Error
• getaddrinfo EAI_AGAIN api.cloudron.io**
  
• The error seems to affect the Cloudron app store as well. Nothing loads...

See repair options below.

This happened after

• I tried to install some NPM packages over the cloudron terminal for NodeBB.
• The install didn't go through (write error)
• I created a temp folder to install NPM and force my way through.

mkdir /tmp/my_modules
cd /tmp/my_modules
chmod -R 777 /tmp/my_modules
npm install nodebb-plugin-calendar@latest

Install stalled and probably didn't go through. The plugins list in NodeBB ACP didn't load properly first. After rebooting nodeBB, it must have broke the container Any suggestions on how to fix this?

Hi Support, I was looking for nodebb-plugins-calendar module which should be available on NodeBB Admin control panel, but I can't seem to find it. This thread indicate that there is an option for it.
https://forum.cloudron.io/topic/7804/nodebb-calendar-plugin?_=1694108522636

Has it been removed recently?