I initially stored my ownCloud data on an external NTFS hard disk. (Yes, this was not a good idea at all.) After some time now I wanted to move the files to a bigger ext4 drive on the same machine. Unluckily there are many posts and articles that are really irritating on the Internet, such as: 1, 2, 3, 4, 5. At least I found some promising hints at the official GitHub forums (this and that) and gave it a try:
At many points, someone noted that it is not officially supported to move the data directory after installation. 
However, the just linked GitHub pages are talking about a method. I tried to copy (cp) all of my files, but ran into some hard disk errors due to broken USB connections on my server. After I tried it again (cp -u), I finally used rsync to copy all of my files, incl. the hidden files that were not copied with cp. These were my steps:
Copy
I first enabled the maintenance mode:
sudo -u www-data php occ maintenance:mode --on
and began to copy my data files (500 GB) from one mount to another. (NOTE: You should skip these steps and use rsync directly, such as explained in a few seconds):
sudo -u www-data cp -r /mnt/ExterneHDD/* /mnt/1TB-VM
But since I ran into some hard disk errors, I used cp again with the -u option to “update” all files:
sudo -u www-data cp -r -u /mnt/ExterneHDD/* /mnt/1TB-VM
After that I set the correct file ownership to www-data:
sudo chown -R www-data:www-data /mnt/1TB-VM
While I was still confused whether all files were copied, I noticed that at least the hidden files such as .htaccess were NOT present at the new file location. A colleague gave me the hint to use rsync, which I tried thereafter. (Refer to here and there.) I first ran the demo mode from rsync. Additionally I set the -P option for progress information and the –stats for final statistics. Also note the critical slashes at both paths. While the first one ends with a slash, the second doesn’t:
sudo rsync -avPn --stats /mnt/ExterneHDD/ /mnt/1TB-VM
(Since I copied from an NTFS hard disk, I also used the –size-only option to compare only the sizes of the files and not the ownership.)
Finally, I ran the following command to copy all broken files which were not copied correctly during my cp runs:
sudo rsync -avP --stats /mnt/ExterneHDD/ /mnt/1TB-VM
Yep, it worked. Great so far.
And ownCloud Changes
Now I changed the “datadirectory” path within the config.php file:
sudo nano /var/www/owncloud/config/config.php
to point to the new mounted drive:
'datadirectory' => '/mnt/1TB-VM/',
And I ran the repair command that was mentioned in the GitHub post:
sudo -u www-data php occ maintenance:repair
This looked like the following (and executed quite fast!):
root@jw-vm12:/var/www/owncloud# sudo -u www-data php occ maintenance:repair
ownCloud is in maintenance mode - no app have been loaded
- Repair mime types
- Repair legacy storages
- Clear asset cache after upgrade
- Asset pipeline disabled -> nothing to do
- Generate ETags for file where no ETag is present.
- ETags have been fixed for 0 files/folders.
- Clean tags and favorites
- 0 tags for delete files have been removed.
- 0 tag entries for deleted tags have been removed.
- 0 tags with no entries have been removed.
- Drop old database tables
- Drop old background jobs
- Remove getetag entries in properties table
- Removed 0 unneeded "{DAV:}getetag" entries from properties table.
- Repair outdated OCS IDs
- Repair invalid shares
- Fix permissions so avatars can be stored again
- Manually copies the third-party folder changes since 9.0.0 due to a bug in the updater.
- Third-party files seem already to have been copied. No repair necessary.
- Rechecking code integrity not necessary.Yeah, after some breathing space I disabled the maintenance mode:
sudo -u www-data php occ maintenance:mode --off
And I was REALLY HAPPY that everything worked again. YEAH! (Though I am still a bit nervous because of this post which talks about some absolute paths within logrotate. I have never used this or heard about it concerning ownCloud. Hopefully, this won’t break my data after a few weeks…)