Cloudron Forum

@darren we can take the thanks as a "This now solved my issue", yes?
If so, you can just upvote this message.

@Njara
When I run the dig NS cofident.net @127.0.0.150 on one of my Cloudron servers, I get.

dig NS cofident.net @127.0.0.150

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> NS cofident.net @127.0.0.150
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27068
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cofident.net.                  IN      NS

;; ANSWER SECTION:
cofident.net.           294     IN      NS      dns102.ovh.net.
cofident.net.           294     IN      NS      ns102.ovh.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.150#53(127.0.0.150) (UDP)
;; WHEN: Fri May 23 12:58:07 UTC 2025
;; MSG SIZE  rcvd: 86

This section is missing on your part:

;; ANSWER SECTION:
cofident.net.           294     IN      NS      dns102.ovh.net.
cofident.net.           294     IN      NS      ns102.ovh.net.

Now I am looking into your generated details https://paste.cloudron.io/imomagiruq

@BrutalBirdie did the changes https://git.cloudron.io/packages/limesurvey-app/-/merge_requests/25
Will be reviewed, and then the app update will be published.

@Aizat
The keydb part needs to be evaluated to get a better understanding how much work is needed to package this app.

@mathieuepitech
Great analysis!
@staff will be very interested about this for further improvement to circumvent such scenarios.

Hello @ChristopherMag

Try to log in with ODIC in a private browser tab and report back if that already is the solution.
Also for npm login with ODIC see => https://docs.cloudron.io/apps/verdaccio/#cli-authentication

Do you mean => https://docs.cloudron.io/apps/#disable-email-configuration?

But very good that you mention the start.sh.
I just took a peek https://git.cloudron.io/packages/limesurvey-app/-/blob/master/start.sh?ref_type=heads#L35-L44

echo "==> Configure email"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('siteadminemail', '${CLOUDRON_MAIL_FROM}')"
# support for single quote in splace name
display_name=$(echo -n "${CLOUDRON_MAIL_FROM_DISPLAY_NAME:-LimeSurvey}" | base64)
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('siteadminname', FROM_BASE64('${display_name}'))"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('siteadminbounce', '${CLOUDRON_MAIL_FROM}')"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('emailmethod', 'smtp')"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('emailsmtpssl', '')"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('emailsmtphost', '${CLOUDRON_MAIL_SMTP_SERVER}:${CLOUDRON_MAIL_SMTP_PORT}')"
$mysql -e "REPLACE INTO lime_settings_global (stg_name, stg_value) VALUES ('emailsmtpuser', '${CLOUDRON_MAIL_SMTP_USERNAME}')"

There is no check surrounding this based on https://docs.cloudron.io/apps/#disable-email-configuration.
This means, the app needs to be updated to include such a check. Otherwise, even when disabling via. the UI this will still try to set it.
Thanks for reporting!

@tadeas
If the Cloudron IP/Domain is rate limited for checking if domain XYZ is blacklisted or not by spamhaus.
It might return a faulty result that will be interpreted into "is on blacklist" by Cloudron.
So yes, this might be a bug from Cloudron.

@staff me might want to look into this scenario.

@skeats you could attempt it yourself. The app is already broken so what can go wrong.

There is no guide for a manual restore since this is something that should not be necessary.
But in this case, sadly is.

If you are not comfortable doing the following, you can contact support@cloudron.io and link this topic in the request.
But you will still need to upload the backup to the cloudron server into a given location from the support.

Now to the gist of it.
The idea would be to install a new Lampstack app. (What is lampstack? Do you mean the LAMP app? Or is this a custom app? I just assume now you are talking about the LAMP app)

Copy the extracted backup to your Cloudron server e.g. /tmp/manual-restore/
In that backup included is the Database as an .sql file and the /app/data/ files.

To import the Database you would need to follow either https://docs.cloudron.io/guides/import-mysql/ and then copy all files of /tmp/manual-restore/
app-backup/data/into/home/yellowtent/appsdata/APPID/data/`

This would be the "manual" way.

@OrezBodajoy
It is always good to check the official documentation for an app.
But in this case, it is a bit misleading.
Since you are using Cloudron, the PostgreSQL access is different.

Creat an app backup first.

If you are in the web terminal of your Invidious app, look to the top right corner.
There is a big green button labeled Postgres.
You can just click that button and confirm with ENTER. Then you are logged into your Invidious PostgreSQL database.

From the official documentation you still need to do:

python3 -c 'import bcrypt; print(bcrypt.hashpw(b"<INSERT PASSWORD HERE>", bcrypt.gensalt(rounds=10)).decode("ascii"))' # python
mkpasswd --method=bcrypt-a -R 10 # mkpasswd

Now you have your new password hash.
Connect to your PostgreSQL database with the described button or copy and paste the following into your web-terminal (the button will print the same into your web terminal):

PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE}

Now you should be able to update the password:

UPDATE users SET password = 'HASH' WHERE email = 'USERNAME';

---

I will request an update of the Cloudron documentation for Invidious to include the password reset with the Cloudron way to do it.
Thanks for reporting this missing documentation and please report back if everything worked out on your part.

~Cheers

@skeats that is problematic indeed.

I asked in External Error - tarExtract pipeline error: invalid stored block lengths:

Are all backups failing or just the latest?

Please confirm this with the question extended.
This is about only one singular app that is not restoring, correct?

If the answer is yes.
Can you download the latest backup to your local system and confirm that it is indeed valid?
If so we could attempt a manual restore of that app.

@skeats the not fully starting unbound service is the biggest culprit here.
The config for unbound is located in /etc/unbound/unbound.conf.d/cloudron-network.conf

# Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org)
# We cannot use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)

server:
        port: 53
        interface: 127.0.0.150
        interface: 172.18.0.1
        ip-freebind: yes
        do-ip6: yes
        access-control: 127.0.0.1 allow
        access-control: 172.18.0.1/16 allow
        cache-max-negative-ttl: 30
        cache-max-ttl: 300
        # enable below for logging to journalctl -u unbound
        # verbosity: 5
        # log-queries: yes

# https://github.com/NLnetLabs/unbound/issues/806
remote-control:
    control-enable: no

@skeats can you please check if port 53 is already in use?

Start with netstat - output from one of my systems:

netstat -tulpn | grep -i -E '.*:53\s+.*$'
tcp        0      0 127.0.0.150:53          0.0.0.0:*               LISTEN      835/unbound
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      656/systemd-resolve
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      656/systemd-resolve
tcp        0      0 172.18.0.1:53           0.0.0.0:*               LISTEN      835/unbound
tcp        0      0 188.245.165.100:53      0.0.0.0:*               LISTEN      1070/dockerd
udp        0      0 188.245.165.100:53      0.0.0.0:*                           1070/dockerd
udp        0      0 172.18.0.1:53           0.0.0.0:*                           835/unbound
udp        0      0 127.0.0.150:53          0.0.0.0:*                           835/unbound
udp        0      0 127.0.0.54:53           0.0.0.0:*                           656/systemd-resolve
udp        0      0 127.0.0.53:53           0.0.0.0:*                           656/systemd-resolve

Does yours look different? Is something else using port 53?

Also the lsof -i :53 command can give some insight:

lsof -i :53
COMMAND    PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r  656 systemd-resolve   14u  IPv4   8685      0t0  UDP _localdnsstub:domain
systemd-r  656 systemd-resolve   15u  IPv4   8686      0t0  TCP _localdnsstub:domain (LISTEN)
systemd-r  656 systemd-resolve   16u  IPv4   8687      0t0  UDP _localdnsproxy:domain
systemd-r  656 systemd-resolve   17u  IPv4   8688      0t0  TCP _localdnsproxy:domain (LISTEN)
unbound    835         unbound    3u  IPv4   9391      0t0  UDP localhost:domain
unbound    835         unbound    4u  IPv4   9392      0t0  TCP localhost:domain (LISTEN)
unbound    835         unbound    5u  IPv4   9393      0t0  UDP my-DOMAIN-TLD:domain
unbound    835         unbound    6u  IPv4   9394      0t0  TCP my-DOMAIN-TLD:domain (LISTEN)
dockerd   1070            root   36u  IPv4  10659      0t0  TCP mail.DOMAIN.TLD:domain (LISTEN)
dockerd   1070            root   41u  IPv4  10660      0t0  UDP mail.DOMAIN.TLD:domain

Please check that and report back. Thanks.

@tadeas it can be that a rate limit interaction with spam house.
Perhaps with some time all notices will be gone.
But please report back if this is not the case.

@Njara I just had to delete your screenshot again, it still or again showed almost the full credentials.
And even worse, now you have uploaded this screenshot to casimages.com.
You will have to reset these credentials since you have now uploaded them to casimages.com.

A good censored screenshot looks something like this.

There is not 1 pixel of any character leaking from the field.
With image AI these days, reconstructing your credentials from bad censored image can be done within seconds.

---

When I run the dig command, I get:

dig NS cofident.net @1.1.1.1 +short
dns102.ovh.net.
ns102.ovh.net.

Which seems correct.
But since you are getting a timeout from Cloudflare (1.1.1.1) there is something wrong with your DNS.

Please connect to your server via. ssh and run the following command:

cloudron-support --send-diagnostics

this will gather all information needed and will provide you a URL like https://paste.cloudron.io/SomeRandomCharString
Please post this URL here so I can take a look at your system and what is wrong with it.

At minimum you will have to provide the output of:

dig NS cofident.net @127.0.0.150

and

systemctl status unbound.service

@d19dotca is this a feature request for Cloudron / haraka (the mail server used by Cloudron)?
If yes, I can fork this to a full feature request topic so we can keep track.
Otherwise, this might get lost in support topic.

@ccfu is correct. We need the mail log for the failing mails to further assist.

Hello @skeats

Sorry that you are having issues when restoring your app. Are all backups failing or just the latest?
Might it be possible for you to test if the second-latest backup works?
I want to confirm if this restore error is just for the latest backup.

The PTR4 and PTR6 record need to be set in the server setting of your provider not your DNS provider.
See => https://docs.cloudron.io/email/#ptr-record

@p44 people here did have great reviews for @d19dotca custom SpamAssasin rules https://forum.cloudron.io/post/105256
That might reduce your spam in the inbox

Hello @sponch

Thanks for reporting.
Are there any error messages in the app log or the browser console when viewing that preview that just blackouts?