Uninitialized string offset: 0 at Node.php#308

[jonathanmmm]

#10262

Hi,

I get

Error	PHP	Uninitialized string offset: 0 at /var/www/nextcloud/lib/private/Files/Node/Node.php#308
Error	PHP	Undefined index: dirname at /var/www/nextcloud/apps/ransomware_detection/lib/Monitor.php#260

very often (multiple times in the same minute and every few minutes)

Probably this problem has to to with php7.4 (had some other issue, disabled already file access control app, as it was somewhere mentioned to make problems, got errors in my log that access was denied to files, that shouldn't be blocked)?
I have Debian Buster with nginx, php7.4-fpm.

I have E2EE enabled, but only one user uses it for one folder.

[TimoHess]

Got same error on all the same php and nextcloud versions. Also fpm.

I don´t have E2EE enabled and use ubuntu 18 lts and apache.

[SigLinJo]

I also get these errors. See attached files. Running in FreeBSD 11 jail on TrueNAS core 12, PHP-fpm, PHP version 7.4.9, NC 19.0.4, Apache24, MariaDB 10.3.23. I have a lot of the following:
Ransomware Monitor error.txt
Node error.txt

I also have an error trying to open a specific folder located on external local storage:
Forbidden No read permissions.txt

Don't know if they are related but as far as I can figure it out the trouble with the specific storage started after update to NC 19. My install has been updated and migrated since OwnCloud whatever version was current 2014 running in a Freenas 9 jail so a lot of chances for old irregularities to be present in the database... The problem with file access is really frustrating!

[GieltjE]

Can confirm, logs are being flooded with this (Gentoo, php-fpm 7.4.13, apache 2.4.46), can help debugging if needed.

[SigLinJo]

I have found some more information. Externally mounted storage don't get it's permissions updated when browsed. What happened to me was that some files got permissions that blocked my nextcloud webserver user, and when that permissions denied had been loaded to the database or something it would not go away. It was still there after Nextcloud migration from TrueNAS jail to Proxmox ubuntu VM, and I finally regained access by unmounting the nfs shares, creating new folders in the mount point forcing flush and rescann of the folder after removing and adding the external storage through nextcloud admin settings in the webinterface. I had to repeat the removal and reconnection of external storage to get nextcloud to recognise the remounted nfs share. It got even more obvious today when my log got filled with errors again and i noticed it was a folder in an other mounted external storage that I had tried to access while www user didnt have read permissions... I removed the folder (redundant copy) and the errors stopped.

Something in the implementation of permission checks in externally mounted storage is not working as expected. Folder and file permission needs to be checked on every access atempt and not get logged as denied and permanently stuck. It is really nice to be able to have storage that lives outside the core data storage so other services can work with the files without breaking the Nextcloud database, and to make that work fully the permissions should update for Nextcloud everytime they update on the file system.

[GieltjE]

Be carefull as some external storages (e.g. sshfs) might not support permission changes at all.

[SigLinJo]

I'm not saying Nextcloud should change the permissions, only that Nextcloud should be able to detect changed permissions. What happened to me: I had one folder that did not have correct permissions when I tried to access it from Nextcloud and I got an error. I then changed permissions on the folder thru the terminal but Nextcloud did not let me access the folder even if it now had full read an write permissions. To fix it I had to remove the mounted storage from Nextcloud, mount something different in the same location, got an error that it had changed (I think that flushed the old info out of the database) unmount that, remount the original storage that now got recognised with proper permissions. What makes this really frustrating is that one instance of permission misshap will block a resourse from beeing accessed permanently.

[GieltjE]

I meant that sshfs wil always have the wrong user/group in some cases in combination with fixed permissions, which might break that detection.

[szaimen]

Is this Issue still valid in NC21.0.2? If not, please close this issue. Thanks! :)

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.