Users cannot acces their home folder after upgrade to 14.0.1: This directory is unavailable, please check the logs or contact the administrator

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version: 14.0.1
Operating system and version: Debian Jessie
Apache or nginx version: Apache 2.4.25
PHP version: 7.0.30

The issue you are facing:
After the upgrade from 13.0.6 to 14.0.1 several user cannot access their home folder. The get the warning: This directory is unavailable, please check the logs or contact the administrator

I’ve checked that the folder for the user actually exists and is accessible for the webserver.

Is this the first time you’ve seen this error?: Yes

Steps to replicate it:

  1. Login as a user and you get the error message.

About the logs below: The user behind “B5252B51-49B3-4D02-B288-0EC5315DE9D8” is an Active Directory user who is actually enabled in AD but who cant loging or doesn’t show up in the user list.

The output of your Nextcloud log in Admin > Logging:

A lot of these generic warnings:

{"reqId":"AZE3pLC1hk9DLrb1rpyW","level":3,"time":"2018-10-02T22:30:04+02:00","remoteAddr":"","user":"--","app":"files","method":"","url":"--","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"--","version":"14.0.1.1"}
{"reqId":"AZE3pLC1hk9DLrb1rpyW","level":3,"time":"2018-10-02T22:30:04+02:00","remoteAddr":"","user":"--","app":"files","method":"","url":"--","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"--","version":"14.0.1.1"}
{"reqId":"AZE3pLC1hk9DLrb1rpyW","level":3,"time":"2018-10-02T22:30:04+02:00","remoteAddr":"","user":"--","app":"files","method":"","url":"--","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"--","version":"14.0.1.1"}
{"reqId":"AZE3pLC1hk9DLrb1rpyW","level":3,"time":"2018-10-02T22:30:04+02:00","remoteAddr":"","user":"--","app":"files","method":"","url":"--","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"--","version":"14.0.1.1"}
{"reqId":"AZE3pLC1hk9DLrb1rpyW","level":3,"time":"2018-10-02T22:30:04+02:00","remoteAddr":"","user":"--","app":"files","method":"","url":"--","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"--","version":"14.0.1.1"}

For a specific user who has this problem:

{"reqId":"bpXH0Dbi4ZPew9CL5N09","level":3,"time":"2018-10-02T22:31:12+02:00","remoteAddr":"10.0.9.7","user":"steerink","app":"files","method":"PROPFIND","url":"\/remote.php\/dav\/files\/steerink\/","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"Mozilla\/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko\/20100101 Firefox\/62.0","version":"14.0.1.1"}
{"reqId":"ZUnFC3pDBVkElCWb963W","level":3,"time":"2018-10-02T22:31:18+02:00","remoteAddr":"10.0.9.7","user":"steerink","app":"files","method":"PROPFIND","url":"\/remote.php\/dav\/files\/steerink\/","message":" Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8","userAgent":"Mozilla\/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko\/20100101 Firefox\/62.0","version":"14.0.1.1"}

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

<?php
$CONFIG = array (
  'instanceid' => 'ocez99cktziw',
  'passwordsalt' => '',
  'secret' => '',
  'trusted_domains' =>
  array (
    0 => '',
    1 => '',
    2 => '',
  ),
  'datadirectory' => '/var/owncloud/intranet-dkb',
  'overwrite.cli.url' => '',
  'dbtype' => 'mysql',
  'version' => '14.0.1.1',
  'dbname' => 'oc_intranet-dkb',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'oc_admin',
  'dbpassword' => '',
  'logtimezone' => 'Europe/Amsterdam',
  'installed' => true,
  'default_language' => 'nl',
  'loglevel' => 2,
  'log_rotate_size' => 104857600,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'mail_smtpmode' => 'smtp',
  'mail_from_address' => 'intranet',
  'mail_domain' => '',
  'mail_smtphost' => '',
  'mail_smtpport' => '25',
  'ldapIgnoreNamingRules' => false,
  'trashbin_retention_obligation' => 'auto',
  'theme' => '',
  'htaccess.RewriteBase' => '/',
  'singleuser' => false,
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
  'auth.bruteforce.protection.enabled' => true,
  'mail_smtpauthtype' => 'LOGIN',
  'maintenance' => false,
  'updater.release.channel' => 'stable',
  'ldapUserCleanupInterval'=> '50',
);

I have absolutely no idea what to do about it. The suggestions on the forum / google I’ve found assumed I know which file ID is blocking but I can’t find a file ID.

Any help is appreciated!

When I had troubles like that, running occ files:scan -all on the server commandl ine fixed the problem

I just spotted jvankempen’s post after spending all day trying to figure this out myself. I just moved our nextcloud installation to a different VM (different OS, so new apache/php7.1/mysql/redis installation).
I thought I made some mistake with the file and database transfer, or the nextcloud configuration.

In a moment of desperation I truncated oc_filecache (I think I saw some suggestion somewhere to do this online). I made a backup of the table before, but not until some of the users had files deleted of their computer. Really? The oc_filecache table would cause that? Even after I ran the ‘files:scan --all’ command?

Anyways, I am restoring the table backup as I am typing this. But something is definitely wrong with 14.0.1.1
I have multiple users who can’t access their home directory on the browser and their client says that there was an internal error (‘can’t find file ID XXXX’ - that’s what lead me to clear out the oc_filecache table).
I already checked the file/folder permission of the data directory. All folders are 750 and files are 640.

If there is any information needed from me, please let me know. Also, why is it that we cannot do a ‘files:scan --all’ with maintenance turned on? I have to turn off maintenance (allow all users to connect) to run a scan.

Hello,
I have the same problem for 3 of my 20 users. When I turn off “file sharing” option they can see their home folders and after reenabling this feature the problem comes back again. Any ideas?

Same here. I was able to restore the oc_filecache table from the backup, but now other users can’t login via the desktop client. BUT turning off the file sharing app made all the errors go away.

But it does render nextcloud somewhat useless for us … :frowning:

1 Like

Hi, May have nothing to do with this issue. but a very similar issue happened to our installation last week. When I set nextcloud up to access our ldap network, I set the internal username attribute to sAMAccountName. When nextcloud was upgraded this seems to have disappeared, which resulted in new accounts now being able access there shared drives.

A quick update on our situation. After investigating, and restoring a backup from a couple days ago (before the migration), we seem to be back to users having access.
I believe the issue arose from our server being overloaded at times. I noticed last evening that MariaDB was serving up ~7000 Selects per second.
I have a ton of ‘Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction’ on the oc_filecache table. And I think it was what got us started on having our database broken until some users could not log in anymore.
I beefed up our MariaDB to be able to handle these massive amounts of requests. It has lessened the amount of log entries, but they are still there.
But I don’t think we have the same issue as OP, and I apologize for sidetracking this thread.

Ok I’ve watched the posting for a week but even tough more people are having similar problems there is no known solutions…
Of course I’ve tried rescanning without any results. My logs are flooded with these kinds of warings:

Error	files	Backends provided no user object for B5252B51-49B3-4D02-B288-0EC5315DE9D8	2018-10-09T21:15:05+0200

@Ian_Parr: I’ve looked into your possibility but the link to our AD is still correct With samAccountName in both options.

Because I build this solution for a small primary school in the Netherlands there is no money for the expensive support.
Is our only option leave Nextcloud and go for the “free” Sharepoint solution (Free as in given for almost free to primary schools in the Netherlands).

Or does it maike any sense to file a bug report?

Any constructive reaction would be appreciated!

I’ve the same Issue with my nextcloud instance after updating to 14.0.1. In other file tabs like ‘recent’ I can access my files. Disabling the share app doesn’t work. My instance is running on debian9 whith apache 2.4.25 and PHP 7.0. Whem I’m using the search bar, the results appear behind the loading circle.

Same issue here. Disabling the file sharing app fixes the problem but losing a key feature isn’t that great of course.
Running Nextcloud 14.0.1 on CentOS7 with nginx connected to a Windows AD with almost 1000 users (we’re using this solution in our school).

So… I’m highly interested in a fix/solution as well. :slight_smile:

Because there a more similar postings I’ve opened up a bug report:

Maybe this helps…

Ok I’ve made some progress. I hope this helps others:

Based on this bug #11550 report I’ve upgraded to 14.0.2 RC2 and the users were able to login again.

Then a recreated the missing users using it UUID and could remove the old shares. The last few defective files and shares were removed after deleting the missing user again.

My problem seems fixed.

Still have this problem on latest nextcloud 21 docker build.

And this makes me doubt the reliability of nextcloud.

hi all,

i have been having the same problem since yesterday. somehow i dont see my home folder in the browser. one of my computers didnt have the icons anymore when using the desktop app (the folders didnt have the green icons). i had to resync that computer and now they are showing correctly again.

it doesnt matter which user i use, it does not work in the browser. i cant access the logs either, the window just keeps loading forever, so i cant even see whats wrong.

if i go to the images folder i can see them normally, or if i access some folder via the activity (if i changed some file and its logged in the activity, i go to the file and from the parent folder i can keep navigating, but the root still doenst load)

i am running the nextcloud on cloudron 6.3.4

Wollo like you I really love working with the command line. But I notice when we give suggestions or answers what we assume that everyone should be able to execute. I’ve been working with Linux now for 5 years, and I still have issue. What I don’t understand is when I see an answer in a Linux or Open source forum that may get me pass a issue, I read an answer like yours " I just run this " with the ideal that I should know what you ran mean. Example: I having a problem with eating a banana, your answer it yellow. You left out the how, the fact that I need to pill back the yellow part before I it. Can you show me how you ran occ files:scan -all. [What, When, Where and Why] I never assume anything this is how we keep new users to Nextcloud.