@solarsimon said in how extensive are backups?: I am sure you can make my worries disappear... @mehdi said in how extensive are backups?: @solarsimon Dumb question but ... have you tried in another browser, just to make sure it's not a cache problem ? no words. It had to be that simple. solved, or better erase

@msbt thanks so much. My interpretation of the fix suggested didn't work. I have posted a follow-up question there.

For future reference i managed to clear it up by using a slightly modified version of Girish's search command. It seems like the length limit applies to path length not just the filename length find . -type f -print|awk '{print length($0), $0}' | sort -n Went into the web interface and deleted / renamed files longer than 156 bytes and finally cleared trashbin/versioned files (wipes all deleted / old versions of files - careful): sudo -u www-data php -f /app/code/occ versions:cleanup sudo -u www-data php -f /app/code/occ trashbin:cleanup @robi @girish agreed it would be awesome if there was an automated way to handle this in the future

@msbt Thank you, that makes sense!

Amazing, and makes all the difference!

@mehdi this was indeed a bug in the restore code path. the setupToken, as you guessed, should be sent in the top level object and not as part of the backupConfig . Fixed now.

@girish great thanks, It works

Yes also from the graphs, the system is just running out of RAM and thus swaps like crazy causing all this CPU and disk I/O. So using those apps, you'd have to upgrade the droplets.

@nebulon I just added a new dns record on Namecheap manually. After this action, cloudron was able to add my second domain

@wisemetalhead whoops, I somehow missed this question. Not sure why the backup listing disappeared, I think we will have to investigate what happened using the logs. But since the backups itself are still there, you can use the CLI tool's cloudron import to restore (if needed).

@ei8fdb right the graphs don't update immediately, but every 6 hours or so. Otherwise, the disk spins a lot I will mark this thread as solved, but this problem will go away soonish. I think only ~20 apps are left to use the new base image. The 7.1 release also updates all the internal containers to use the latest image. Should all be done end of this month.

@girish no, I mean, like nothing ever happened in that it worked perfectly (via the interface, not CLI). Should have been more articulate in my response but was just so excited how easy it was!

I did a clean installation and restored a backup. Since than, everything is working fine. Thanks

@reachableceo thanks for the update!

Thank you all, I only thought the port forwarding of 80 was enough, Thank you for all the help for explanations

@3246 @girish , I am not sure (didn't try myself) but things suggested in this post may help ..

@girish thanks! That's indeed the fix..

It's fixed a bit differently. The purpose of the "profile lock" feature is that admins have control over the username/mail/display name. Letting the user choose the username would circumvent this. This more so applies because when you have multiple admins, maybe one admin forgot to set the username (but they had decided by policy that they won't allow users to set usernames themselves). Given that the profile lock is a 'dynamic' flag i.e can be set/unset at anytime, the fix we have put in place is: username can now be set already created users with no username. When profile lock is set, username is required when creating new users. This way it's not possible for an admin to create users without a username. When profile lock is set, invite links of users with no username show a message to contact admin. (This message will only be seen if you had users created with no username and set the profile lock later. So, it's kinda rare)