Where are the files?

Hello! I want to upgrade owncloud but first I decided to make a backup following the documentation.

The problem is I can’t find the files for each user. If I navigate to /var/www/owncloud/data I see I have a symlink to /mnt/owncloud_data/data, because during the installation I choose script guided installation.

Where are the files stored? I go in the folder /data and I find all the folders for the respective users, inside the /files folder there is nothing.

I have checked permissions and configurations and all seems ok, my installation is relatively new and I followed the instructions in the documentation without much customization.

The thing is that all the files are synchronized and users can see them, but I cant find them when I ssh in the server, not in the /mnt path, not in the owncloud/data path.

Could anybody explain me where they might be? Are they being stored locally, maybe?


Server configuration

Operating system:
Ubuntu 18.04.5 LTS
Web server:
Apache/2.4.29 (Ubuntu)
Server version: 10.5.9-MariaDB-1:10.5.9+maria~bionic mariadb.org binary distribution
PHP version:
PHP 7.4.16 (cli) (built: Mar 5 2021 07:54:20) ( NTS )
Copyright © The PHP Group
Zend Engine v3.4.0, Copyright © Zend Technologies
with Zend OPcache v7.4.16, Copyright ©, by Zend Technologies
ownCloud version: (see ownCloud admin page)
Updated from an older ownCloud or fresh install:
fresh install
Where did you install ownCloud from:
Signing status (ownCloud 9.0 and above):

Are you using external storage, if yes which one: local/smb/sftp/…
Are you using encryption: yes/no


please link the documentation site you were following.

I would look in /mnt/owncloud_data/data

Best Regards


1 Like


this is the documentation I followed:


Yes, the path where I looked for the data is ‘/mnt/owncloud_data/data’.

I have syncronizations done from different computers, and I realized only the data that is directly syncronized from one of the computers is not there ‘/mnt/owncloud_data/data’
But the syncs done from other computers are storing data in ‘/mnt/owncloud_data/data’ properly.

Where could I look in that computer who is not storing data in ‘/mnt/owncloud_data/data’? I have checked, there are no errors…

I think might be a matter of users.
The syncs done by 2 users are ok.
Just the sync done by that other user is not storing the data on the server.

Wild guessing: in user panel, the Storage Location field for that particular user points somewhere else.

1 Like

Hi, I dont have any specific Storage Location configured, I think you mean external storage.

Have you verified the Storage Location field for that failing user?

1 Like

@mmattel could you have a look? Not sure about the scripted installation.

1 Like

Might be anything related to virtual files?

These files must be somewhere because every other user can have access to them when they log in into their accounts.

But they are not in /mnt/owncloud_data/data when I check the files in the server via ssh.

And I didnt modify the settings in config.php after the scripted installation.

Yes, I checked, there is nothing specific configured for storage location in any user.

Hello @wildwebmaster, thanks for using ownCloud and Central for your questions. You start your post with the comment above. Just to be on the same page - pls clarify if different, you already have an existing standard ownCloud installation which you want to upgrade. For this upgrade, you use the guided script. If both is true, this would explain what you see and can be solved easily.

A default installation has its data directory as full part of your ownCloud root (owncloud/data) where the data directory is not linked to another location. When using the script and decide to use a link (which is a very good choice btw) then the data directory is a link to another location which then looks like owncloud/data --> /mnt/owncloud_data/data. This means when you cd into owncloud/data you see the content of /mnt/owncloud_data/data. As you did not installed the very first time using a link for the data directory (the script would ask you if you want or not), there is no content in /mnt/owncloud_data/data and therefore no user data - which is what you see. One benefit of the script is, that it avoids in place upgrades and a lot of copying of user and downloaded app data. This means your old installation is still present but renamed including all the files.

To get your user data back, put your instance into maintenance mode, stop the webserver and copy all user directories from owncloud_timestamp/data to /mnt/owncloud_data/data using the preserve rights and permissions flag (-p). The directory structure should then look quite identical. You can, if you want to be on the safe side, re-run the script after this task without doing an install or upgrade, just to set the correct rights and permissions. When done, disable maintenace mode and start the webserver and you are fine. The copy process is only needed once and on the next upgrade, your linked data directory will be used if you select using links.

I will take your comment and improve the documentation accordingly.

Please let me know if you have further questions.

Many Thanks,


Hello @mmattel, thank you very much for all your explanation. The documentation about the guided script was perfect, I did a fresh installation from that (not an upgrade yet).

I just found out what my problem was and why I couldn’t find the files. The files were actually in the /mnt/owncloud_data/data folder, I just wasn’t looking for the data in the right place. It seems that data gets stored only inside the folder that belongs to the user who created that data, but not in the other users folders.
As an example, if a user log in owncloud website, that user can see all the folders and files that have been shared with them. But if I go inside that user’s folder in the server, /mnt/owncloud_data/data/“username-folder”/files, it is empty, because the files are stored only in the user’s folder who did the syncronization with the owncloud client.

Thanks everyone for the replies and support.


Great to hear @wildwebmaster that things got sorted out. Please do not hesitate to contact us in case of questions.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.