UNSOLVED Importing existing backup in new app instance fails
however as said, the error does not seem to be related to LDAP module
I understand, that's why I suggest to do a "normal" migration to a new instance to see if that works and then activate LDAP.
Did you in any way interact with the freshly installed instance prior to importing the backup?
No, didn't even logged in the first time, is that needed?
@nebulon just did every step you suggested again, this time no such 755 error but still same issue with no CSS and also no scripts (I guess because clearing cache within that scambled GUI didn't work).
@nebulon I tried 2 other attempts from start and none worked out. Last scenario I did login the new app before importing backup and then the GUI was "normal", right after import it was wrong again.
The only thing I can think of is that I have the following modules active and maybe because of "phone home" to check licenses (they are only for 1 domain) it breaks the app? (Actually I doubt it, because the very first time I changed the subdomain to the current and that also didn't work).
I probably would have to debug this on your system then, don't seem to be able to reproduce the issue here. If you use the webterminal into the app, can you see
/app/code/storagebeing a symlink to
I will move those topics to a new thread since this is more like a general restore issue it seems.
@nebulon very good you moved this to a new thread.
On another Cloudron I just migrated (only migrate with no single module) a Freescout instance (this one is rather new, only 4 weeks and only few emails) and that went perfect.
The Cloudron/Freescout app that has the issues is already from the very first version and updates went fine.
The app is 1.98GB in size according to Cloudron System Info, however, when I calculate size on SCP login, the /appsdata/[ID]/data/ folder is 2.11GB and the mysqldump is 189.8MB.
If you use the webterminal into the app, can you see /app/code/storage being a symlink to /app/data/storage ?
In the current app it is symlink (bright blue is symlink I guess) together with Modules.
I don't keep up the migrated Freescout up for longer than a few minutes because that one is fully functional and fetches email and response with autoanswers. Is there an easy way to stop cron to prevent mixing of data between 2 of the same instances?
@imc67 right you would have to stop the app to avoid interfering with the mailboxes.
just out of curiosity, did you restart the failing app after import? I don't quite get why
storage/framework/cache/would not be writeable, if the symlinks are there.
You can also try to run
sudo chown -R www-data:www-data /app/datasince that would set the permissions for the files in the symlinked files. Although that would be done on an app restart anyways.
this time no such 755
After the second try (see above) there was no such error anymore, so I don’t think we should look into that direction. But also don’t know in what direction to think either
@nebulon hope you have time somewhere coming days to debug this issue together?
- Tried to follow you steps 5 times to migrate a Freescout instance (1.98GB + 189.8MB mysqldump, since the first version on Cloudron)
- Only the 1st time not only failed the "CSS/scripts" but also somehow the symlink.
- All the other 4 times only failed with a GUI without (looks like) CSS and some buttons (scripts?) are not working (login is possible with LDAP) see screenshot
- A migration of Freescout on another Cloudron went fine (only 4 weeks old instance with hardly any mails).
- Just as a debug scenario I just cloned the current app and that also didn't work, same result with GUI/CSS/script.
@nebulon hopefully you can find time this week to debug together as we now have the premium LDAP plug-in but can’t use it
@imc67 actually I have tried again but was not able to reproduce your issue to be able to debug this. Maybe this is really somehow related to the backup size of your instance Not sure how to debug this properly.