You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently in the process of migrating my personal Nextcloud away from Nextcloud's first-party S3 support because of its incompatibility with encryption, which you can read about in this issue thread here. In the thread, Jivan Pal suggests using s3bracker instead.
I am also trying to migrate from the Nextcloud Snap appliance to the Nextcloud Docker appliance, because the Snap has some annoying limitations. (Among other things, it doesn't support URL rewrites and it doesn't support Apache virtual hosts for more than one appliance per VPS.) My hope is that the Docker appliance will be as low-maintenance as the Snap appliance, as compared to being able to manage all the components manually.
Anyway! The Nextcloud Docker readme lists the following as data volumes, i.e. what I could use with s3backer:
If you want to get fine grained access to your individual files, you can mount additional volumes for data, config, your theme and custom apps. The data, config files are stored in respective subfolders inside /var/www/html/. The apps are split into core apps (which are shipped with Nextcloud and you don't need to take care of) and a custom_apps folder. If you use a custom theme it would go into the themes subfolder.
Overview of the folders that can be mounted as volumes:
On the other hand, Docker recommends using volumes rather than bind mounts. Is s3backer something I would use in this scenario? If so, do you have any recommendations as to how?
Thanks!
Best,
Elsie Hupp
P.S. I'm cross-posting this to the s3backer-devel mailing list because I'm not sure which of these is a better place to post this, and I'll link between the two threads.
The text was updated successfully, but these errors were encountered:
The directory structure is as follows : /var/www/html/data/$USERNAME/{cache,files,files_trashbin,files_versions,uploads}
The easiest way to use s3backer would be to have /var/www/html/data be an s3backer backed filesystem. In my testing for my own setup (not docker), this results in extremely poor performance.
My recommended setup for using s3backer with Nextcloud is to have /var/www/html/data be on the local filesystem.
Then have only /var/www/html/data/$USER/{files,files_versions,files_trashbin} be on s3backer.
So, when a user uploads a file, it is uploaded to the uploads folder, which is on the local filesystem. This is then moved to the files folder at server's leisure, and latency here is acceptable.
For similar reasons, I keep cache on the local filesystem.
I am not sure if docker allows adding volumes in the configuration to meet this specific requirement, as I don't use it, but you should be able to use a mix of docker volumes and bind mounts to achieve this.
I'm doing same thing as you, but i do differents structures:
I modify the nextcloud to put cache outside the data ('cache_path' => '/var/www/html/cache')
I use s3backer for the whole data directory but i do a mout --bind for appdata_XXXX, files_encryption and updater-XXXX
With this configuration new accout will be on s3bucket
Hi
s3backer
Folks!I am currently in the process of migrating my personal Nextcloud away from Nextcloud's first-party S3 support because of its incompatibility with encryption, which you can read about in this issue thread here. In the thread, Jivan Pal suggests using s3bracker instead.
I am also trying to migrate from the Nextcloud Snap appliance to the Nextcloud Docker appliance, because the Snap has some annoying limitations. (Among other things, it doesn't support URL rewrites and it doesn't support Apache virtual hosts for more than one appliance per VPS.) My hope is that the Docker appliance will be as low-maintenance as the Snap appliance, as compared to being able to manage all the components manually.
Anyway! The Nextcloud Docker readme lists the following as data volumes, i.e. what I could use with s3backer:
On the other hand, Docker recommends using volumes rather than bind mounts. Is s3backer something I would use in this scenario? If so, do you have any recommendations as to how?
Thanks!
Best,
Elsie Hupp
P.S. I'm cross-posting this to the
s3backer-devel
mailing list because I'm not sure which of these is a better place to post this, and I'll link between the two threads.The text was updated successfully, but these errors were encountered: