Separate user data from application data in data directory

[k-svn]

I would like to separate user data from application data in the data directory. The goal is to store only the user files on a nfs share. If I change the path of the data directory in config.php to the share, there is also application data like appstore_ and updater-.

Can't the several user directories be created in another subfolder "users"? This folder can then be relocated with a symlink.

Maybe there is already a possibility?

[bdrewery]

A symlink or nullfs/bind mount does not work on the appdata dir?

[solracsf]

See also #12873

[k-svn]

Say, we relocate data directory to a nfs share. Then you have a lot to link back to local file system, because we want only user data on the share:

├── appdata_XYZ (relocate via symlink)
├── audit.log (relocate via symlink)
├── index.html (relocate via symlink)
├── user1
├── user2
├── updater.log (relocate via symlink)
└── updater-XYZ (relocate via symlink)

Why are the users not located in a subdirectory?
Then you keep the data directory in the local filesystem and relocate just users dir to nfs share:

├── appdata_XYZ
├── audit.log
├── index.html
├── users (symlink to nfs share)
          ├── user1
          ├── user2
├── updater.log
└── updater-XYZ

I hope you know what I mean

[systemofapwne]

I stumbled upon the same problem today and I really wish for better separation of real user-data and application data.
Moving user-data in a subfolder, as @k-svn suggests, might be the most straight forward solution IMHO.
Right now, I am using some bindmount magic in my container, where I actually mount the appdata_/updater-XYZ inside of the whole "userdata" folder, that itself is bindmounted to my SMB shares. That is kind of an ugly but working workaround. So its is far from being an acceptable solution.

Here is an except of my currently working workaround in my docker-compose file. Replace XYZ with your specific instance-id

version: '2.4'
services:
  cloud:
    image: nextcloud:latest
    ports:
      - "28080:80/tcp"
    restart: always
    volumes:
      # Storage
      - "/mnt/nextcloud/userdata:/userdata:rw"                        # SMB share
      - "/home/cloud/userdata/appdata_XYZ:/userdata/appdata_XYZ:rw"   # Ugly workaround (Local filesystem)
      - "/home/cloud/userdata/updater-XYZ:/userdata/updater-XYZ:rw"   # Ugly workaround (Local filesystem)

[bestlinuxgamers]

Perhaps this could also be combined with variables for mount paths. That would allow for even finer control. Perhaps a local folder (mounted via NFS/SMB/...) could also simply be used through the "external storage" add-on in the future.
But for now, it would definitely help if we could at least place the user folders into a separate directory.

[stavros-k]

I'm curious why this is still not implemented, I mean I can see real value for large organizations.

• appdata_$instanceid, index.html, etc being on fast storage (ssd etc)
• user data being on HDDs, network storage etc.

This would provide a huge speed improvements in large systems.
Unless administrator does hacks of mounting docker volumes or symlinking things (on direct host installs), each request will hit HDDs to fetch index.html, fetch previews from appdata etc.
And note that those "hacks" only work after you initialize the instance. Because the instance id is not known beforehand