Data directory is invalid Please check that the data directory contains a file “.ocdata” in its root

Nextcloud version (eg, 20.0.5): 25.0.4
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
PHP version (eg, 7.4): 8.0

The issue you are facing:

Hi!
When I call the website I get a white page with the message “Data directory is invalid Please check that the data directory contains a file “.ocdata” in its root.”
I’m using Plesk and I made a mistake by switching to PHP 8.2 Switching back didn’t work because something was messed up and I had to delete the subdomain. For that I saved the nextcloud folder
deleted the subdomain, created a new subdomain and copied everything back. And now I’m getting this message.
Directory /opt/nextcloud/data was set on installation and contains a .ocdata file.
All threads concerning this topic seem to be caused by a move of the data directory, but this is not the case for me.
Any help is appreciated!

Best regards

Is this the first time you’ve seen this error? (Y/N): Y

The output of your Nextcloud log in Admin > Logging:

I can't login

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'instanceid' => 'id',
  'passwordsalt' => 'salt',
  'secret' => 'secret',
  'trusted_domains' =>
  array (
    0 => 'nextcloud.my.domain',
  ),
  'datadirectory' => '/opt/nextcloud/data',
  'overwrite.cli.url' => 'https://nextcloud.my.domain',
  'dbtype' => 'mysql',
  'version' => '25.0.4.1',
  'dbname' => 'db',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
  'maintenance' => true,
  'mail_smtpmode' => 'sendmail',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_from_address' => 'me',
  'mail_domain' => 'my.domain',
  'mail_smtpsecure' => 'tls',
  'mail_smtphost' => 'smtp.my.domain',
  'mail_smtpport' => '587',
  'theme' => '',
  'loglevel' => 2,
  'mail_smtpauth' => 1,
  'app_install_overwrite' =>
  array (
    0 => 'calendar',
  ),
  'filelocking.ttl' => 21600,
  'default_phone_region' => 'DE',
);

Can anyone give me a hint what to do?

If there is the .ocdata file, then it could be a problem with permissions. PHP usually runs under a different user (not sure what plesk is setting) let’s imagine that it is user user1:
sudo -u user1 ls -lisa /opt/nextcloud/data
should show you the folder and the permissions of the .ocdata file.

If you have firewalls and config-limitations, it can be helpful to check logfiles, if there are problems it might show up.

1 Like

Thanks for the reply!

The command shows this:

 user1@me$ ls -lisa /opt/nextcloud/data 
total 153500
79694760      4 drwxrwx---  7 user1 psaserv      4096 Feb 19 08:05 .
79433995      4 drwxr-xr-x  3 root   root         4096 Mär 30  2018 ..
79826740      4 drwxr-xr-x 15 user1 psacln       4096 Nov 20  2021 appdata_ocansgmdkno3
79826741      4 drwxr-xr-x  2 user1 psacln       4096 Mär 13 20:30 files_external
79694764      0 -rw-r--r--  1 user1 psacln          0 Mär  4  2020 flow.log
79694761      4 -rw-r--r--  1 user1 psacln        542 Mär 13 20:30 .htaccess
79694765      0 -rw-r--r--  1 user1 psacln          0 Mär 13 20:30 index.html
79691930  50348 -rw-r-----  1 user1 psacln   51499000 Mär 23 21:25 nextcloud.log
79691929 102504 -rw-r-----  1 user1 psacln  104862744 Feb 19 08:05 nextcloud.log.1
79694763      0 -rw-r--r--  1 user1 psacln          0 Mär 13 20:30 .ocdata
79826742      4 drwxr-xr-x  7 user1 psacln       4096 Nov 16 21:31 user1
79826743      4 drwxr-xr-x  6 user1 psacln       4096 Jan 29  2021 user2
79694768    616 -rw-r--r--  1 user1 psacln     623195 Mär 13 20:30 updater.log
79826744      4 drwxr-xr-x  4 user1 psacln       4096 Mär 13 20:31 updater-ocansgmdkno3

I guess I screwed something up, because I don’t think index.html, .htaccess and so on should be in there.
Do I have to reinstall?
Best regards

In this thread a just now have seen, that those files seem to be alright.

yes those files should all be there.

but I don’t think the permissions are set correctly.

what user runs apache webserver

Do you mean permissions within the nextcloud folder?
Because I didn’t touch anything in /opt/nextcloud/data and before I deleted the subdomain everything was working just fine.

what is the output of your installation directory

ls -la /var/www/nextcloud

if you copied/moved the files as a normal user permissions might have changed.

Because I’m using Plesk the path is a little bit different, but that’s the output

proton@mydomain  ~  ls -la /var/www/vhosts/mydomain.de/nextcloud.mydomain.de                     
total 184
drwxr-x--- 15 proton psaserv  4096 Mär 28 00:11 .
drwx--x--- 25 proton psaserv  4096 Mär 28 09:15 ..
drwxr-xr-x 47 proton psacln   4096 Mär 13 20:30 3rdparty
drwxr-xr-x 61 proton psacln   4096 Mär 13 20:30 apps
-rw-r--r--  1 proton psacln  19327 Mär 13 20:30 AUTHORS
drwxr-xr-x  2 proton psacln   4096 Mär 20 21:17 config
-rw-r--r--  1 proton psacln   4095 Mär 13 20:30 console.php
-rw-r--r--  1 proton psacln  34520 Mär 13 20:30 COPYING
drwxr-xr-x 23 proton psacln   4096 Mär 13 20:30 core
-rw-r--r--  1 proton psacln   6317 Mär 13 20:30 cron.php
drwxr-xr-x  2 proton psacln   4096 Jul 20  2019 data
drwxr-xr-x  2 proton psacln  16384 Mär 13 20:30 dist
-rw-r--r--  1 proton psacln   3345 Mär 13 20:30 .htaccess
-rw-r--r--  1 proton psacln    156 Mär 13 20:30 index.html
-rw-r--r--  1 proton psacln   3456 Mär 13 20:30 index.php
drwxr-xr-x  6 proton psacln   4096 Mär 13 20:30 lib
-rw-r--r--  1 proton psacln    283 Mär 13 20:30 occ
-rw-r--r--  1 proton psacln      0 Mär 17 13:06 .ocdata
drwxr-xr-x  2 proton psacln   4096 Mär 13 20:30 ocm-provider
drwxr-xr-x  2 proton psacln   4096 Mär 13 20:30 ocs
drwxr-xr-x  2 proton psacln   4096 Mär 13 20:30 ocs-provider
-rw-r--r--  1 proton psacln   3139 Mär 13 20:30 public.php
-rw-r--r--  1 proton psacln   5549 Mär 13 20:30 remote.php
drwxr-xr-x  4 proton psacln   4096 Mär 13 20:30 resources
-rw-r--r--  1 proton psacln     26 Mär 13 20:30 robots.txt
-rw-r--r--  1 proton psacln   2452 Mär 13 20:30 status.php
drwxr-xr-x  3 proton psacln   4096 Mär 13 20:30 themes
drwxr-xr-x  2 proton psacln   4096 Mär 13 20:30 updater
-rw-r--r--  1 proton psacln    101 Mär 13 20:30 .user.ini
-rw-r--r--  1 proton psacln    383 Mär 13 20:30 version.php

see how the owner here is proton where your data directory is user1. change your datadirectory owner also to proton.

sudo chown -R proton /opt/nextcloud/data

My bad, I don’t know if it can cause problems when someone knows my username so I changed it when posting here. This time I forgot it. So user1 is actually proton, sorry. :confused:

Can you check your datadirectory path in your config.php? Had the same issue yesterday and my path wasn’t set correctly.

I checked but it seems like it’s the right path 'datadirectory' => '/opt/nextcloud/data', :slightly_frowning_face:

Are you on shared hosting?

Do you mean virtual server? If so, the answer is no, I have root access to the server.

can you run occ commands

you should run below command after restoring from a backup

sudo -u www-data php /var/www/vhosts/mydomain.de/nextcloud.mydomain.de/occ maintenance:data-fingerprint

also you may remove .ocdata from this directory /var/www/vhosts/mydomain.de/nextcloud.mydomain.de

you can also try occ maintenance:repair

Running /opt/plesk/php/8.0/bin/php occ maintenance:data-fingerprint had no output.

/opt/plesk/php/8.0/bin/php occ maintenance:repair produced this output:

 - Repair MySQL collation
     - All tables already have the correct collation -> nothing to do
 - Repair mime types
 - Clean tags and favorites
     - 0 tags of deleted users have been removed.
     - 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.
 - Repair invalid shares
 - Move .step file of updater to backup location
 - Add move avatar background job
     - Repair step already executed
 - Add preview cleanup background jobs
 - Migrate oauth2_clients table to nextcloud schema
     - Update the oauth2_access_tokens table schema.
     - Update the oauth2_clients table schema.
 - Fix potential broken mount points
     - No mounts updated
 - Repair language codes
 - Add log rotate job
 - Clear frontend caches
     - Image cache cleared
     - JS cache cleared
 - Clear every generated avatar on major updates
 - Add preview background cleanup job
 - Queue a one-time job to cleanup old backups of the updater
 - Cleanup invalid photocache files for carddav
 - Add background job to cleanup login flow v2 tokens
 - Remove potentially over exposing share links
     - No need to remove link shares.
 - Clear access cache of projects
 - Reset generated avatar flag
 - Keep legacy encryption enabled
 - Check encryption key format
 - Remove old dashboard app config data
 - Add job to cleanup the bruteforce entries
 - Queue a one-time job to check for user uploaded certificates
 - Repair DAV shares
 - Add background job to set the lookup server share state for users
 - Add token cleanup job
 - Clean up abandoned apps
 - Add possibly missing system config
 - Deduplicate shared bookmark folders
     - Removed 0 duplicate shares
 - Remove superfluous shared bookmark folders
     - Removed 0 superfluous shares
 - Remove orphaned bookmark shares
     - Removed 0 orphaned shares
     - Removed 0 orphaned public links
 - Remove orphaned bookmark tree items
     - Removed 0 orphaned bookmarks entries
     - Removed 0 orphaned folders entries
     - Reinserted 0 orphaned children entries
     - Removed 0 orphaned bookmark folders
     - Reinserted 0 orphaned bookmarks
 - Update bookmark group shares
     - Removed 0 users and added 0 users to 0 groups
     - Removed 0 shares
 - Upgrading Circles App
 - Fix component of birthday calendars
     - 3 birthday calendars updated.
 - Regenerating birthday calendars to use new icons and fix old birthday events without year
     - Repair step already executed
 - Fix broken values of calendar objects
    0 [->--------------------------]
 - Registering building of calendar search index as background job
     - Repair step already executed
 - Register building of social profile search index as background job
 - Registering background jobs to update cache for webcal calendars
     - Added 0 background jobs to update webcal calendars
 - Registering building of calendar reminder index as background job
     - Repair step already executed
 - Clean up orphan event and contact data
     - 0 events without a calendar have been cleaned up
     - 0 properties without an events have been cleaned up
     - 0 changes without a calendar have been cleaned up
     - 0 cached events without a calendar subscription have been cleaned up
     - 0 changes without a calendar subscription have been cleaned up
     - 0 contacts without an addressbook have been cleaned up
     - 0 properties without a contact have been cleaned up
     - 0 changes without an addressbook have been cleaned up
 - Remove activity entries of private events
     - Removed 0 activity entries
 - Clean up old calendar subscriptions from deleted users that were not cleaned-up
    0 [----->----------------------]
     - 0 calendar subscriptions without an user have been cleaned up
 - Remove invalid object properties
     - 0 invalid object properties removed.
 - Fix the share type of guest shares when migrating from ownCloud
 - Copy the share password into the dedicated column
 - Set existing shares as accepted
 - Clean up meta table
 - Update OAuth token expiration times
 - Create help command
 - Invalidate access cache for projects conversation provider
     - Invalidation not required
 - Cache the user display names
 - Switches from default updater server to the customer one if a valid subscription is available
     - Repair step already executed
 - Send an admin notification if monthly report is disabled
 - Initialize migration of background images from dashboard to theming app
 - Add background job to check for backup codes
 - Populating added database structures for workflows

But the website is still inaccessible.

because I’m not sure how permissions are in your system can you check if it helps if /opt/nextcloud/data is set to 775

sudo chmod 775 /opt/nextcloud/data

see if site loads

if not you can revert

currently it is set to 770 where the optimal is 750 but this depends on user preferance.

I set all everything to 777 just to be sure. Site wouldn’t load.

I’m out of ideas without logs.

tail -f /var/log/apache2/access.log
maybe domain_access.log
whatever you setup in apache conf vhost

you get any output from occ user:list
no need to share just a yes or no will do

see if there is anything logged in /opt/nextcloud/data/nextcloud.log it seems changed on march 23 in your screenshot which is after you posted.