Cloudron Forum

@girish @girish Thank you for that response.
I understand that each app is installed in a container. Which it looks like is a Docker container.
I have sftp access to the root of my entire website linux volume, which contains all of the folders of dependencies. I see the Cloudron installation and its dependencies. The entire file structure of my website server is open to me. There is no other volume adjacent to this Linode volume. Nothing can exist outside of this root in my server volume.

The Docker container for Mastadon must be on this volume -- I have the complete website volume exposed.
The path you refer to is not showing up, which is where I started looking yesterday. It is as if this Mastadon installation has been filed under an "assumed" name and path.

Would you tell me, or point me to a diagram of the folder structure that a Cloudron installation will show and the logic it uses to then containerize each new Marketplace application?

I have SFTP access to my volume where Cloudron is installed and the Mastadon application is running . I have also an SSH terminal opened as search alternative.

I cannot find with either method the location path of the application of Mastadon now running. None of the usual path folders and wild card searches have gotten me to the Mastadon application. Exploring the Docker container files is not helping me either.

The usual terminal commands are also coming up empty as far as locating the Mastadon app folders.
Can you tell me what folder paths I should be looking for when Cloudron is the default admin application on this volume? Where Cloudron installs its Marketplace applications, please?

@ccfu I have CHANGED the Email Server domain that Cloudron set when I enabled Incoming Email reception.
I changed it Back to my base domain, removing the my prefix.
And then I Reset the DNS to update my Linode server.
At first the only error was an SPF but it resolved a few minutes later.

I have Green Lights again.
Thank you for your help.

I am trying to resolve the communication frustration, though. I went through all the standard steps of Install.
Setting the Email server to enable Incoming email at my domain DID set the MX server at Linode to use "my.currentdomain.de" I never chose this prefix and never entered it either at my Linode server configuration or in my Cloudron panel.

Several times the responses I have gotten was that I must have made up this configuration. I also read several times in our communications that it "has nothing to do with your MX Server", yet also saying that it was the COMPARISON between the mismatching MX Server value and the base url. So, both things can not be true. The PTR errror DID have everything to do with the MX Server value.

In our communications I made it clear that for me to change or modify the MX Server value I was going to my Linode Server account dashboard. Especially with the caveat that the PTR value had to be set at my Linode account.

Yet, you were evidently referring to going to the Cloudron dashboard and

1. to go first to the right side Admin panel to bring up Email Settings and then
2. click on Mail server location and the checkbox pencil.
3. Make the change there in the Edit function ... removing my. and saving there.
4. And then I had to go back out of the Owner admin window and
5. to the other Cloudron Email Configuration Status control and hit REDO DNS SETUP.

So now I know by trial and error that to fix the PTR error I reported that I must REJECT the default Cloudron setup which installed the MX Server setting at my Linodes volume with a prefix my.

That I must go through the above steps in my Cloudron Admin panel to finally fix the error.

RESOLVED. Thank you for putting up with all of this!

@DeBossNow said in PTR problem between Linode & Mastadon:

I mistyped this ... I changed the MX Server at linode to the base domain "currentdomain.de"

Nevertheless, I CHANGED THE MX server at Linode from "my.currentdomain.de" to the base domain url "mycurrentdomain.de" for my Mastadon installed website.

@ccfu I had no MX record when I set up the new server at Linode yesterday.
After I chose to use the Default Cloudron smtp server THEN Cloudron asked for permission to go setup the MX Server.

When I returned to the linode dashboard i saw the updates that Cloudron did. The MX Email server was set to the same address as the Default Cloudron Login Panel url for this domain.

Hence, the MX Server said ... my.currentdomain.de was the address for my Email server. I did not choose the my. prefix for this.

Nevertheless, I CHANGED THE MX server at Linode from "my.currentdomain.de" to the base domain url "mycurrentdomain.de" for my Mastadon installed website.
I waited now for 10 minutes, refreshing my Email status report every minute. PTR error still showed that it was expecting "my.curentdomain.de".

But then I re-enabled the Cloudron email server to RECEIVE Emails at my domain instead of just being able to Send emails from his domain.

Then up popped this --

When I clicked the Enable button within a minute back at Linode Cloudron had RESET my MX Record to --

my.currentdomain.de This is the Cloudron Email setup default.

So, the PTR record error at cloudron persists
RESETTING the MX Record as you suggest does not get rid of this error.

I CAN go back to Linode and OVERWRITE what the Cloudron Email (enabled Incoming email reception, too) MX Server has saved ... my.currentdomain.de .... but it seems like that will mess up this Incoming email service, since it is Cloudron that specified this.

@ccfu Thank you for your help.
I understand that you have a lot on your plate, so I appreciate your expertise.

But, my willingness to help or cooperate is not necessarily reflected by failing to understand you.

What you have just asked me I have included as Copy and Paste directly from both my Linode server and from my Cloudron dashboard -- only obscuring IP and Domain name.

My Cloudron Dashboard
Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.de

**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10

But i literally can not get this same value saved as a PTR record.

Linode server Configuration --

A/AAAA Record

Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xx

Cloudron PTR check says that it wants to find a DNS record that reads as

my.currentdomain.de IP Public xx.xx.xxx.xxx

But all Cloudron reports is finding my base domain name. currentdomain.de

The next entry that the PTR script should find is
my.currentdomain.de IP Public xx.xx.xxx.xxx

but when I ADDED that subdomain record ...
writing
my.currentdomain.de
IP xx.xx.xxx.xxx
It always saves just as

my IP xx.xx.xxx.xxx

Every subdomain prefix with period. and full domain name that I add will only save in the field as the prefix.

The Edit function after the fact does not make any difference either.

@scooke This is such a minor problem.
The solution is easier to leave Cloudron, proportionately, than leave the Linode hosting over such a minuscule problem.

Just the PTR check. It bothers me to see it when it could be resolved by revising the PTR script at Cloudron to understand that it must append the base domain to the subdomain DNS entries it finds. Because Linode JUST saves the naked prefix in that field.

The Cloudron PTR check a couple of years ago was reported by more than me in the forum as persisting in this error that could not be changed at Linode. They just do not save anything but the individual prefix for each subdomain DNS reverse entry.

All subdomains in the A/AAAA records at linode are saved by prefix only --
my (not my.currentdomain.de)

mail (not mail.currentdomain.de)

@ccfu l understand the interface problem.
I did not start in this stuff a week ago.

I am telling you that the PTR check is what does not understand, so to speak, the "Interface problem".

I do not have access to the Cloudron PTR check script to modify it for what it finds when it checks the server configuration at linodes.

It is an inteface mismatch not with ME but with the internals of the script. It does not find the literal string "my.currentdomain.de" -- it obviously ONLY finds "currentdomain.de". There is an adjacent record at Linode that should contain the value "my.currentdomain.de" just as the MX record contains.

But I cannot edit, I cannot add that DNS reverse lookup value as "my.currentdomain.de". And, obviously Linode does not read out that full prefix with base domain name to the Cloudron PTR script.

I thought this would be simple. I am done. I thank you for all your help, everyone.

@ccfu I know that it is not really stripped out.
I know that.
What I am saying is that the Cloudron PTR checking script does NOT include this value.
It is reporting back that it wants to find the literal string "my.currentdomain" but all it finds is "currentdomain.de" and that it is expecting to find "my.currentdomain.de".

I am incredibly frustrated by now. I cannot report it more clearly than I have. About 3 years ago I read about the SAME PROBLEM on this PTR check with Linode. I never saw a solution. Emails worked. Move on. Ignore it seemed to be the consensus.

I was hoping in 2023 this would be resolved.

@DeBossNow
If I had an account at Hetzner, for instance, I could do what I am used to doing for years and years --

currentdomain.de -- IP xx.xxx.xxx.xx
my.currentdomain.de -- IP xx.xxx.xxx.xx

but when I write and save at Linodes the subdomain prefix my. or any other prefix mail. or whoopee. etc is STRIPPED from its base domain and gets saved, no matter what as --

my -- IP xx.xxx.xxx.xx

@colonelpanic Thank you for trying to help.

I REALLY DO KNOW BACKWARDS AND FORWARDS WHAT I CAN SET IN MY LINODES ACCOUNT.

I HAVE SET UP 6 WEBSITES, ALL NODE.JS ETC AT LINODES.

I HAVE MADE MANY MORE VOLUME SETUPS FOR DIFFERENCT SCENARIOS

THERE IS JUST NO WAY THAT USING THE LINODE TOOLS I CAN ADD A SEPARATE DNS ENTRY IN THE A/AAAA Records that assigns my public IP address to an entry that reads the following string --- my.currentdomain.de
If I could literally save that value then, presumably, the Cloudron PTR would be satisfied.

LITERALLY the Linode DNS tools, once the main domain name is entered, the Sub domains such as MY or WHATEVER.currentdomain.de will NOT SAVE AS SUCH.

The base domain name is STRIPPED out ... leaving only the PREFIX of the sub domain.

@ccfu
"Cloudron just checks that there is a PTR record that matches the mailserver hostname. Also the server environment is irrelevant."

If this was happening as you say then the Cloudron check would be happy with the MX record. NO Error.

As I showed -- the reason I INCLUDED IT Twice now --
is that the MX record, while set up BY Cloudron when I elected to use the default SMTP server for outgoing mail -- then set by Cloudron as my.currentdomain.de -- does NOT SATISFY the PTR check

Obviously, the PTR check keeps referring to the A/AAAA Records. It SCANS NOT the MX record which IS my.currentdomain.de ---
but focuses on looking for another kind of record.

I did not install a separate email server app. I am just using the vanilla Cloudron email server setup which GENERATED the MX Record on my Linode server.

i do NOT WANT TO CHANGE anything more.
But the PTR check is reporting that is it finding
my standard DNS reverse currentdomain.de linked to my public IP. And it is demanding that to be happy that it finds a PTR record that literally contains this string --
my.currentdomain.de

This is just plainly NOT HAPPENING as you describe:
"you can change it to domain.xx so that it matches the PTR record."
I WANT THE PTR TO JUST LOOK AT MY MX RECORD AT MY SERVER AND STOP REPORTING AN ERROR.

How many times can I repeat this and still confuse you?
IF the PTR Check in Cloudron was simply referring to the MX Record my.currentdomain.de then NO ERROR.
All I can do is REPORT what Cloudron's PTR Check is showing me. ERROR.

@DeBossNow It seems obvious that the PTR check should recognize that the Linode server environment is Different from, say, Hetzner, etc. and knowing that important fact it will adjust its expectations for that PTR string and give it a green light.

A simple if/or/then check to handle the query back to the Linode environment where Cloudron is installed.

@BrutalBirdie Thank you.
But, as I have written -- I showed and described what I can do on my server side. I KNOW that the PTR is set on my server side.

But, as I wrote --- the Linode UI tools for the A/AAAA adminstration will write that value as -- my
NOT my.currentdomain.de

And this apparently works fine for thousands and thousands of sites set up for hundreds of thousands of Linode users with all kinds of apps.

Only Cloudron, that I have run across, demands to see this record as -- my.currentdomain.de
The setup which it only does once -- in the MX record -- but NOT in the records the Cloudron PTR check is looking for -- in the A/AAAA records.

Cloudron PTR check is the anomoly here unless someone has ACTUAL EXPERIENCE WITH LINODE and found a work around.

All i get in the File Manager view is this a barebones system folder that is empty of files. The split view just repeats the same columns again. The Download is an empty zip file.

I want a view like your docs show --

But this is all I get. It can't be drilled down into the installed application files.

@jdaviescoates Yes, I have read this. Thank you.

But it resolves to just saving the prefix my even when I enter my.currentdomain.de

It seems that my Cloudron function, the actual value it is checking for, would have to be changed in the script itself to remove the PTR error. It is looking for a literal my.currentdomain.de string and can not resolve simply seeing a my by itself.

I have successfully installed Cloudron after creating a new server volume at Linode. And it installed Mastadon within 5 minutes. Success at last.

Now I see a problem that I first encountered a couple of years ago when setting up the standard Cloudron Email. Emails will work correctly but in the Email configuration window I see this familiar error again.

the following --

Email configuration
The PTR record is set by your VPS provider and not by your DNS provider.
Hostname: xx.xx.xxx.xxx
Record type: PTR
Expected value: my.currentdomain.de
Current value: currentdomain.de

**At my Linode dashboard I see that Cloudron has set the
MX Record to be
Mail Server Preference Subdomain
my.currentdomain.de 10

But the PTR check expects to see in my Linode configuration a complete my.currentdomain.de as well, instead of simply my

Linode Configuration --

A/AAAA Record

Hostname IP Address
currentdomain.de xx.xx.xxx.xxx
my xx.xx.xxx.xxx

I cannot get this record to change to my.currentdomain.de ---- Linode does not allow it to be saved this way. It by default reverts to simply my

I've looked through the forum history and done online searches but I don't find a resolution to making this PTR Error disappear in my Cloudron dashboard. Linode tech support refers back to my Cloudron account to somehow resolve the error. I may have to live with this error as long as I am using Linode but as far as I know the emails work.

Does someone using Linode and Cloudron have a way to resolve this problem in 2023?
Thanks for any relevant helpful answers!

@ccfu VERY GOOD
I WILL REPORT THIS TO LINODE.
But I am still stuck with, apparently, an outdated resource being referred to HERE at Cloudron for my in-limbo Mastadon install.

App Info
App Title and Version
Mastodon 4.1.2
App ID
14a48c54-804a-49e1-b794-17f1046585db
Package Version
org.joinmastodon.cloudronapp@1.11.4
Last Updated
20:16:19
App not found
There is no such app org.joinmastodon.cloudronapp with version 1.11.4.
No new updates available

What steps should I take to complete this Mastadon install with an updated script?

@ccfu How have I made a False Accusation?
The Marketplace at Linode shows only the approved versions of Install Apps. These are the only ones that use the actual app icons and specific details.
I did not choose from the Community Scripts.
I chose Mastadon Install from the approved Marketplace.
That is the same place where the Cloudron Install is also listed separately.
I have been with Linode for over 3 years and had my first account with Cloudron for a couple of years, too.
Here is where I reported discovering in the past hour plus that my Cloudron dashboard is reporting that IT CANNOT FIND THE SOURCE REFERRED TO IN THE CLOUDRON SCRIPT FOR MASTADON .
https://forum.cloudron.io/topic/9134/app-not-found-there-is-no-such-app-org-joinmastodon-cloudronapp-with-version-1-11-4

@scooke Sorry to hurt your feelings, but, I accurately reported the situation at the Linode Marketplace where the CLOUDRON INSTALL SCRIPT is identified by the MASTADON ICON instead of the Cloudron icon and when clicked continues to identify itself as the Mastadon source install.