@jdaviescoates Yes, the latest app update has resolved the issue!

Thank you for your help with this, though.

By default, Nextcloud generates photo thumbnails on-demand that leads to slow Photos thumbnails load. To speed it up we’re using the Preview Generator app for Nextcloud to pre-generate previews regularly.

First we set the default thumbnail sizes by using the "occ config" commands:

sudo -u www-data /usr/bin/php /app/code/occ config:app:set --value="32 256" previewgenerator squareSizes sudo -u www-data /usr/bin/php /app/code/occ config:app:set --value="256 384" previewgenerator widthSizes sudo -u www-data /usr/bin/php /app/code/occ config:app:set --value="256" previewgenerator heightSizes

Then we generated previews for all existent images:

sudo -u www-data /usr/bin/php /app/code/occ preview:generate-all -vvv

It took about 3 weeks on our host to generate preview images for 4Tb of data which takes additional 500Gb.

Once it's finished we setup a cron job to generate previews:

0 */6 * * * sudo -u www-data /usr/bin/php -f /app/code/occ preview:pre-generate

TBH, it helped us a little but our Photos are still loading for 50-60 seconds and we are seeking any solution to speed it up.

@zion you can do both at the same time. If you create a account within Nextcloud, Cloudrons LDAP is not involved. The other way around you can deny access for Cloudron accounts via the apps security tab within Cloudron. Switching off LDAP is not recommended but you are free to do whatever you like ^^

@SamGreenwood said in Nextcloud not responding:

Jitsi is now doing the same thing

As @nebulon said before: A little information would help, like

Hoster Domain / DNS provider Ubuntu Version

etc etc

@nebulon Yes, it seems like it is: https://help.nextcloud.com/t/how-to-remove-device-session-on-security-personal-menu/107430

https://help.nextcloud.com/t/disconnect-all-sessions-revoking-access-for-all-apps-of-a-user/37955/8

Waiting for an official fix, two workarounds mentioned in these topics are editing database or running a bash script. Nothing that I'm able to do, but yeah, this does need to be solved upstream.

@imc67 one way to solve it (temporary?) is to clear cache and cookies

@humptydumpty said in Auto Backups - Data Retention and Syntax Questions:

auto, 7

I think this is the one. This would translate to delete all files in the trash bin that are older than 7 days automatically, delete other files anytime if space needed.

(I think D is just notation for doc purposes)

Has anyone already found a solution for this problem?

Best regards,
Daniel

@MichaelF have you been able to try on things? If so, is there something you could share from your findings, please? 😃

@vladimir-d there seems to be no easy way to migrate nextcloud to different data directory (atleast in an automated way), see https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170 . Looks like the put the absolute path in the "share" database fields.

Also, the reason for nextcloud update is that it has some slightly tricky optimization to change ownership of files carefully. It also changes the default data directory of newer nextcloud installations.

@marcusquinn said in Nextcloud Collectives actually looks good as a Notion/Outline-type alt for documentation:

Nextcloud Collectives

https://apps.nextcloud.com/apps/collectives

https://nextcloud.com/blog/all-about-collectives-its-founders-mission-and-use-cases-create-a-collective-today/

thanks, gonna give this a whirl too

@girish ok, this was my mistake, I changed the cloudron admin name here in the forum for privacy reasons and then tried to use this name back on the server 🙄

@chminc Indeed, I looked into this quite recently myself for our setup and came to very similar conclusions. It's not advised to use object storage. We will move to volume storage in case the space on the server won't be enough - it is not that much more expensive. But I have made really good experience with the Cloudron backup function, it restored everything completely error-free. And you can store the backup on object storage. Using encryption is not a problem at all.

just an update, the syntax for the psql variables has changed, so the conversion script looks like this:

sudo -u www-data php occ db:convert-type \ --password ${CLOUDRON_POSTGRESQL_PASSWORD} \ --clear-schema --all-apps pgsql \ ${CLOUDRON_POSTGRESQL_USERNAME} \ ${CLOUDRON_POSTGRESQL_HOST} \ ${CLOUDRON_POSTGRESQL_DATABASE}

you must run this from within the nextcloud container.

also, I had some dificulties with the mysql migration, the temp mariadb/mysql docker container should match the same type and version as the source. In my case src had mariadb 10.5, so the container from the code sample above (mariadb 10.1) throw some strange errors while importing the sql dump.

@andreasdueren We used to use RC 3 years ago for another project, but had to switch for many reasons.

We even had a partnership with the team behind RC, good people, who at the time could not deliver on our needs in time.

Defintely worth a re-evaluation next go around.

Can confirm that works:

760e579f-21be-44ab-80f0-79b8f296d28d-image.png

@jdaviescoates This is an idea I have quickly considered as well but one reason why I want to move this installation to Cloudron so desperately is that I want to have less work with it, not more 🙂

We will probably need to live with the fact that we will need to re-share all information again and simply do the move using one of the manual ways (e.g. user migration plugin). That will create chaos for a day or two, but at least then we will have a more stable installation.

@derin mine is 8GB good enough for not stress about it. I think it better go higher so we don't had to worry about it much but always make sure you had enough:)