Cloudron Forum

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!

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!

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.

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?

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.

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?