Cloudron Forum

Disabled all my extensions. But when I download a fresh version of Firefox (136.0.2), I don't reproduce the issue. So it must be me...

I have two different cloudrons. New this morning, trying to login to apps on either one is giving me a totally blank page on Linux Mint 21.2, Firefox 133.0.3.

After clearing all cookies and browser settings, when I go to my Cloudron homepage at my.example.com, I get redirected to a page of the form https://my.example.com/openid/interaction/<randomcode>, which appears totally blank.

Getting out chromium, the page still works there.

Yeah, this was resolved by turning off Adguard and resetting unbound to its default settings. Sorry for the hassle.

By the way, the main reason for the DNS changes was for accessing domain.tld from inside my own home network.

$ host -t NS domain.tld
domain.tld name server ns5.linode.com.
domain.tld name server ns1.linode.com.
domain.tld name server ns3.linode.com.
domain.tld name server ns4.linode.com.
domain.tld name server ns2.linode.com.

$ host -t NS domain.tld 127.0.0.150
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases: 

domain.tld has no NS record

Oh, I see the question. Yes, I guess what happened is that I added Adguard and started using it for DNS.

Sorry, from your reply, it may have sounded like I am literally using example.com. To clarify, I had replaced my domain with example.com above. I am using a domain that I own and have nameservers configured for. I'll edit to try to make this more clear.

Hi, I didn't see anyone else with this error when I searched. I own a domain that we'll call domain.tld for this post. I have Cloudron installed at my home (residential) server at "my.domain.tld". My services run on subdomains such as "subdomain.domain.tld", etc. Cloudron is configured to dynamically update DNS through my provider, Linode.

**The problem:**Letsencrypt certificate renewal is hanging:

Nov 10 01:55:12 box:dns/waitfordns Attempt 190 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:55:32 box:dns/waitfordns Attempt 191 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:55:52 box:dns/waitfordns Attempt 192 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:56:12 box:dns/waitfordns Attempt 193 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:56:32 box:dns/waitfordns Attempt 194 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:56:52 box:dns/waitfordns Attempt 195 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:57:12 box:dns/waitfordns Attempt 196 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:57:32 box:dns/waitfordns Attempt 197 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:57:52 box:dns/waitfordns Attempt 198 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:58:12 box:dns/waitfordns Attempt 199 failed. Will retry: queryNs ENODATA domain.tld
Nov 10 01:58:32 box:reverseproxy ensureCertificate: error: queryNs ENODATA domain.tld

This error makes sense because I don't have "domain.tld" configured with the nameserver to point anywhere. I only have configured DNS for "my.domain.tld", "subdomain.domain.tld", etc.

But this has never been a problem before. Can anyone help me with how should I fix it?

Wow, thanks, that was fast! I'm not seeing the error any more.

We're using Zulip and it's incredible. The organization of channels into sub-topics is perfect. The LaTeX integration is also huge for us. It has some nice quality of life features and just generally works really well for us. Cloudron integration would be great.

I am running into the same error message mentioned here: https://github.com/advplyr/audiobookshelf/issues/2854

When I scan a library, the log gives:

FATAL

[Server] Unhandled rejection: ReferenceError: structuredClone is not defined, promise: Promise { <rejected> ReferenceError: structuredClone is not defined at LibraryItemScanData.checkLibraryItemData (/app/code/server/scanner/LibraryItemScanData.js:241:41) at LibraryScanner.scanLibrary (/app/code/server/scanner/LibraryScanner.js:188:60) at async LibraryScanner.scan (/app/code/server/scanner/LibraryScanner.js:82:22) }

Edit: fixed. I found docker.service inside /etc/systemd/system/multi-user.target.wants/

I didn't get this to happen: "Then, systemctl start my-disk-mounter would automatically start docker and box." But that's ok. I run a manual startup script that prompts for the encryption password, mounts the disk, then starts all the systemd services. Instead of my-disk-mounter.service, I have check-that-all-disks-are-properly-mounted.service which is Required by box and docker. Thanks again.

Thank you, @girish !

I had the same question and a very similar motivation. In my case, the boot disk is not encrypted, but an external disk where I store some of the apps' data, like my photos, is encrypted. (By the way, one nice benefit of encrypting a disk is that when it fails, you can just get rid of it without as much worry that personal information can be recovered.)

In my experience, the apps don't handle it gracefully when the server boots first and the external drive is mounted second. I have to manually go through and restart each app after that.

It sounds like a good solution is to set box.service to not start automatically, and to start it manually once I decrypt and mount the external drive?

Well, I uninstalled and reinstalled the gitea app and I don't reproduce the issue -- cloning now works. Sorry if I've wasted anyone's time. If it happens again, I'll try to diagnose why and report back.

Thank you, I have been using that command to debug though without success so far. I am not behind Cloudflare or any firewall.

I only have one ssh key on the machines I am using to test. I verified it in the Gitea interface, but it is rejected:

$ GIT_SSH_COMMAND="ssh -vvv" git clone ssh://git@gitea.example.com:29418/user/test-repo.git
# ...
debug1: Next authentication method: publickey
debug1: Offering public key: /home/linuxuser/.ssh/id_rsa RSA SHA256:XXXXX explicit agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
# ...

I am curious about the difference between these command formats for cloning a repo:

git clone ssh://git@gitea.example.com:29418/user/test-repo.git  # Cloudron Gitea
git clone git@gitea.example2.com:user/test-repo.git  # non-Cloudron Gitea

I also get this difference: with Cloudron,

$ ssh -p 29418 git@gitea.example.com
git@gitea.cutheory.dev's password:

but with non-Cloudron,

$ ssh git@gitea.example2.com
Hi there, user! You've successfully authenticated with the key named <keyname>, but Gitea does not provide shell access.

I am looking at issues like this (maybe on the wrong track). https://github.com/go-gitea/gitea/issues/11050
Thank you for any help. Will report back if I find anything.

Hmm, I still get the same behavior after adding that .ssh/config. (Both machines I'm testing from only have one ssh key, if it matters.)

I am getting this error on a fresh install as well, call it gitea.example.com:

$ git clone ssh://git@gitea.example.com:29418/user/test-repo.git
Cloning into 'test-repo'...
git@gitea.example.com's password: 

I wondered if it's possible the port is wrong, and the command is trying to ssh into the machine as user git, instead of trying to log in. I did try from two different machines with their own ssh keys. I also tried with a verified public key:

$ git clone ssh://git@gitea.example.com:/user/test-repo.git
Cloning into 'test-repo'...
git@gitea.example.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Thank you! I had forgotten that we can turn the Cloudron incoming mail server off, so it won't try to set DNS records. It's working for me now.

Roundcube has to be installed on the VPS server and not in your home server.

It would be fun to be able to run an email client from Cloudron, e.g. with POP to fetch mail from the VPS. That would help with the data sovereignty point mentioned above. But for now, I'll celebrate getting email working at all.

Any advice on how to migrate repositories and access permissions from a Gitea instance that is not on Cloudron to a fresh Gitea instance on Cloudron?

My first choice would be to modify the steps in Gitea's Backup and Restore, though I'd have to sync the users and permissions correctly somehow.

But if I could access the gitea command line, I'd be okay with trying to take it from there manually. It's not a large instance at all. However, I think the cloudron doc about how to access the Gitea CLI is outdated. I guess it has to do with docker now, but I'm not sure how.