Cloudron Forum

@DeBossNow The path mentioned by @girish is like he said: @girish said in Can not locate Mastodon app core folders: in a container and thus each app's filesystem is independent and separate So your statement: @DeBossNow said in Can not locate Mastodon app core folders: 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. Is still factually wrong, since you seem not to know or understand that each container has their own filesystem in their isolated container environment. So even if you have root access to your server, you will not find /app/code in the servers filesystem. Since there are isolated and it's inside the container and read-only. And yes you can still access each container like he even explained to you how you can access the filesystem: @girish said in Can not locate Mastodon app core folders: To navigate the filesystem of the app, use the web terminal. Usually, the package keeps the code in /app/code by convention. Note that code is readonly in Cloudron, you cannot change it. What do you wish to achieve here? There is a big documentation for Cloudron: https://docs.cloudron.io/ which explains almost everything. Adding to that the Forum has many resources which already answer almost any of your questions. And yet it seems to me, you simple choose to ignore all the provided resources for self education and demand support on a level which is unreasonable for a forum request. Personal note: The community behind Cloudron and FOSS in general is very forgiving when you show the effort, and when you reach out for help, they almost always respond. (not always in the nicest way, since they maybe seen this question for 50x time, but they still respond to help out.) So I recommend to you, show some more effort or at least write your request in a more descriptive way. What is it that you are trying to achieve What did you do to get to your current state Provide a step by step level so people can understand what you do - maybe use a service like https://asciinema.org/ Since I preached about resources and self education - here is some material: About the Cloudron Filesystem: https://docs.cloudron.io/storage/ About the Mastodon app and federation: https://docs.cloudron.io/apps/mastodon/ The Mastodon Cloudron Forum category: https://forum.cloudron.io/category/41/mastodon

@DeBossNow The content is based on the app. In the docs screenshot, it's an emby installaton. Where in yours it looks like it is mastodon app. What is shows is just the contents of the /app/data directory. Only the files you see above are editable. If you want to see application files (source files), you have to use the web terminal - https://docs.cloudron.io/apps/#web-terminal . Note that application files are readonly and cannot be changed.

@DeBossNow I am glad you got it resolved, but just to clarify: The MX record is for incoming email. It needs to be set to any domain name that resolves to your server, i.e. has a valid A record. If both my.currentdoain.de and currentdomain.de resolve then you can use either for incoming mail. The mismatch was not with the MX record but between the mailserver domain set in Cloudron and the PTR record of the server. At no point did I or anyone else tell you to change the MX record, and no, the PTR error had nothing to with the MX record. I can therefore only assume that you interpreted MX as being something it is not. For outgoing mail you need a valid PTR record that matches the mailserver domain. You also need a valid SPF record and a valid DKIM entry. Because you set up Cloudron via the Linode app you have presumably told Cloudron to use Linode DNS, which is why it is updating / overriding certain settings. If you do not want it to do that you need to set DNS to manual for the resepctive domain(s). The bottom line is: The PTR record and mailserver domain have to match. Where you make the changes depends solely on the domain you want to use for email, i.e. where the entry needed updating to match. Btw, I stated every time that you needed to check / update the mail domain in Cloudron, not in the Linode dashboard.

@DeBossNow I think maybe something is getting suck in the setup. Can you check /home/yellowtent/platformdata/logs/box.log ? You can do a systemctl restart box in another terminal and check what the logs are saying.

@DeBossNow it would really help if you could give more context on what you refer to when pasting plain text from presumably the Cloudron dashboard. If this is somewhere from the app configure UI, is the app in error state or which state is it in? Is the repair button enabled for that app and if so, have you tried to click that?

@nebulon Awesome! Muchas Gracias!

@nebulon Thank you for taking a look! My problem has just been solved! It started for me because your DOCS did not make it clear that Creating a Mailbox was a whole separate Necessity even for the ADMIN. And that as an ADMIN who Added a User with the whole Email Invitation sent, user responding, creating their own Username, and Saving this DID NOT by DEFAULT at least finish the process by Adding a new mailbox corresponding to the new User . I never guessed that THE ADMIN him or herself of the Cloudron installation would not have access AS THE ADMIN to setup Master default parameters for the Email App itself! In your docs after following along with the entire Email setup down to the check the Status instructions at last continuing down the page it merely says, casually, as if an Option -- *Mailbox Add Mailboxes can be created for Users and Groups on a per-domain level. To do so, simply create them in the Email view.* Mailboxes can be created for Users when it should really be highlighted as Now mailboxes must be set up here for your users if you intend to offer this as a feature. Nothing indicating that we are continuing in the Enabling Emails for Users instructions or after all of the above it still won't work. That not even the ADMIN now enacting all these steps Must manually install an Email box for him/herself. How about "Finally, you must Finish this process by adding each User's Mailbox manually. These were not created automatically when you finished creating the User. In fact, You must first make an Email Box for yourself with Superadmin privileges or you will not be able to Login to the Email application to customize it according to your preferences. It was finally only by reading carefully https://forum.cloudron.io/topic/4529/cloudron-email-wrong-usernam that I realized any advice I received about my email problem was ASSUMING that I knew this -- even though everytime I read your Docs I was assuming that the Mailboxes were automatically installed, certainly for the Admin first of all. I'd recommend really emphasizing this in your docs as a clear Step 1 through Step 10(?) process REQUIRED Final step or not even the Cloudron Admin can enter his own Email installation.

@debossnow said in I don't understand Linode install of cloudron: How do I confine different applications to be installed in the directory of the VPS I am choosing to install into? Just to re-iterate. This is not possible with linode marketplace images, it's not designed to work that way. You cannot choose "app x" and say install it in this existing VPS. Each app always installs on a fresh linode.

@debossnow In Cloudron you can easily change the domain of any app by using the gear icon and the location section menu.

@debossnow Do I have to install a particular ADMIN PosgreSQL tool in my Cloudron application to see & administer this Mastadon database? You can use the Weberminal to get shell like access. On the top there will be button for Database access. And to see all my files & their paths in a UI do I need to install a separate directory or file browser in my Cloudron application? Like the Web Terminal you can use the File Manager to see your files. The path in the File Manager is always /app/data/.

This got sorted out by @ntnsndr by contacting linode support. The VM had to be rebooted after linode unblocked port 25.