Migrating ownCloud on Shared Hosting: Domain Changes, trusted_domains, and Document-Root Moves

Why ownCloud breaks the moment the domain or path changes

ownCloud stores far more than a theme and a few options in its database. It keeps absolute filesystem paths, the canonical site URL, and a list of host names it will accept requests from. When you copy the installation to a new account, rename the domain, or shift the application from public_html into a subfolder, the server address and directory layout no longer match what ownCloud recorded during its first setup. The result is predictable: a blank page, a redirect loop back to the old hostname, or the blunt error screen reading that access through an untrusted domain is not allowed.

The protection responsible for that last message is trusted_domains, an array in config/config.php. ownCloud refuses to serve any request whose Host header is absent from this list, which stops host-header poisoning but also stops your freshly migrated copy from loading. Alongside it, the overwrite.cli.url, datadirectory, and dbhost / dbname / dbuser values all encode environment-specific details that a plain file copy carries over unchanged. A migration is really three coordinated edits: the files on disk, the rows inside MySQL, and the half-dozen keys in config.php that glue them to the new location.

On a Managed Cloud shared plan you perform every step without root. There is no shell access to run the occ maintenance commands that a server admin would reach for, so the work happens through cPanel Jupiter or DirectAdmin Evolution: File Manager to move and edit files, phpMyAdmin to export and import the schema, and MySQL Databases to create the destination user and grant. The CloudLinux PHP Selector should be set to the same PHP major version the source used (ownCloud 10 runs cleanly on PHP 8.1), because an application copied onto a mismatched interpreter will throw fatal errors that masquerade as migration faults.

Copying the application files and the data directory

Begin at the source account. ownCloud has three pieces that must travel together: the application code (the folder containing index.php, config/, and apps/), the data/ directory holding user files and the SQLite journal, and the database. The data/ directory is frequently the largest and is often placed outside the webroot for safety, so confirm its real location by opening config/config.php and reading the datadirectory line before you archive anything.

In cPanel File Manager, select the ownCloud root folder and use Compress to build a .zip or .tar.gz. Do the same for the data directory if it lives elsewhere. Download both archives, then upload them into the destination account and extract them into the intended target — for a domain-root install that is /home/USER/public_html, and for an addon or subdomain it is the document root shown in cPanel's Domains area, for example /home/USER/cloud.example.com. DirectAdmin users follow the identical pattern under File Manager and the Domain Setup paths. Extracting on the server rather than re-uploading thousands of small user files avoids FTP timeouts and preserves the directory tree intact.

After extraction, verify permissions. Files should be 644 and directories 755; the data/ directory and config/ must be writable by the account user, which they already are under a per-user PHP handler on CloudLinux. If you relocated the data directory, note its new absolute path now — you will write it into the config in the final section. Do not open ownCloud in a browser yet. Loading the application before the database and config are aligned can trigger a partial re-initialization that writes a stray config and complicates recovery.

Exporting and importing the database with phpMyAdmin

On the source account, open phpMyAdmin from cPanel, select the ownCloud database in the left tree, and choose the Export tab. Use the Custom method so you can set the format to SQL and, under output options, enable Add DROP TABLE — this lets the import overwrite cleanly if you need to repeat it. Download the resulting .sql file. ownCloud tables share the prefix you chose at install, usually oc_, and the export captures all of them including oc_storages and oc_filecache, which hold path references you may need to inspect later.

On the destination account, create the target database and user first. In cPanel open MySQL Databases, add a new database, add a new user with a strong password, then attach the user to the database with All Privileges. DirectAdmin bundles this into a single MySQL Management → Create Database form. Record the fully qualified names — shared hosting prefixes both database and user with your account name, producing values like cpuser_owncloud and cpuser_ocuser. Return to phpMyAdmin, select the empty destination database, open the Import tab, choose your .sql file, and run it.

If the dump is larger than the upload limit, raise upload_max_filesize and post_max_size temporarily by adding a .user.ini in the account home or using the PHP Selector Options editor, then import. For very large files, split the export by table groups rather than fighting the ceiling. Once the import finishes, confirm the table count matches the source. The same careful export-import discipline applies to any database-backed app — the Mautic database maintenance guide covers repairing tables if an import reports errors mid-way.

Rewriting config.php: trusted_domains, overwrite.cli.url, and the DB block

With files and database in place, open config/config.php in the destination webroot using File Manager's Edit action. This single file controls whether the migrated instance answers at its new address. Update the database block to the names you just created:

'dbname' => 'cpuser_owncloud',
'dbhost' => 'localhost',
'dbtableprefix' => 'oc_',
'dbuser' => 'cpuser_ocuser',
'dbpassword' => 'the-password-you-set',

Next replace the trusted domains and the canonical URL so the new host is accepted and all generated links point to it:

'trusted_domains' => 
 array (
   0 => 'cloud.example.com',
 ),
'overwrite.cli.url' => 'https://cloud.example.com',
'datadirectory' => '/home/cpuser/owncloud-data',

Set datadirectory to the real extracted path from the previous section — a wrong value here produces an immediate "Data directory is invalid" screen. If you changed the document root but kept the same domain, only datadirectory and the DB block need attention; if you only changed the domain, focus on trusted_domains and overwrite.cli.url. Keep the instanceid, passwordsalt, and secret values exactly as copied from the source, because regenerating them invalidates stored encryption keys and user password hashes.

Because you cannot run occ, force a clean cache by enabling maintenance mode through the file itself. Add 'maintenance' => true,, save, load the site once (it will show the maintenance page), then set it back to false. This clears the appstore and routing caches that otherwise retain the old URL. If the move included HTTPS, confirm an .htaccess redirect enforces the canonical host so ownCloud never receives the bare or www variant it does not trust:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^cloud\.example\.com$ [NC]
RewriteRule ^(.*)$ https://cloud.example.com/$1 [R=301,L]

Load the site and sign in with an existing account. If files appear but previews fail or sharing links still carry the old domain, re-check overwrite.cli.url and the oc_storages table, where a home:: entry pins the data path. When login succeeds and files sync, the migration is complete — keep the source account and its archives untouched for a few days as a rollback target before removing them.