[Bug]: Shares missing in web when 'mount_provider_class' is empty #34752
Comments
SystemKeeper
added
bug
0. Needs triage
|
So this does not happen with all files. When I just set the mount_provider_class to NULL for a random file, everything still works and the mount_provider_class is correctly set after the page is reloaded. I still have a user and a file where this problem occurs. |
|
I expect that this #33540 should already fix this. if the problem persists, feel free to reopen |
|
cc @icewind1991 |
|
right, so possibly that one didn't catch everything like your issue |
|
@icewind1991 could you maybe take a look at this? :) |
|
On my occasion, privileges on some files, granted implicitly through conversations, were be lost. |
PVince81
added
regression
1. to develop
|
@icewind1991 would clearing oc_mounts be a good workaround then ? |
|
note: there's more info in #34976 about different affected setups |
|
potentially related to #34976 (comment) probably need another approach for the fix? |
|
The setup logic should fallback to performing a complete setup when it finds a cached mountpoint without a mount_provider_class set, so I'm confused why setting it fixes the issue for people |
|
If somebody that has the issue and has the ability to attach a debugger or add some debug logging to check what the value of server/lib/private/Files/SetupManager.php Line 405 in bd91c56 When trying to open the files the |
|
@icewind1991 Log entry for a missing Talk file is: This is followed by the default log output of line: server/lib/private/Files/SetupManager.php Line 437 in 417f46e Log entry: Does this make sense for you somehow? Please let me know if you need further debugging lines. |
|
@icewind1991 I'm sorry, I am a bit lost here. First I tried to dump I can't access the file directly, because it's not visible in the web interface. Opening the directory with the iOS app does show shared files, but this one is not listed. Trying to do a direct download like curl -u <....> -H "OCS-APIRequest: true" -X POST "https://<...>/ocs/v2.php/apps/dav/api/v1/direct" -d "fileId=208394"results in <?xml version="1.0"?>
<ocs>
<meta>
<status>failure</status>
<statuscode>404</statuscode>
<message></message>
</meta>
<data/>
</ocs>When I try Trying what @XueSheng-GIT suggested results in the same Let me know what you need! |
|
In the current case the file was shared to a talk conversation (as seen above), but that particular user is not part of the conversation anymore. Maybe relevant - could you check on your side @XueSheng-GIT if that's the case as well? |
|
In my case it seems to mainly affect one user. The user who shared the file is still part of the room (conversation). |
The user who shared, yes, but also the „problematic“ user? In my case User A shared a file to a conversation, where User B was a participant at some point. Now User B is not a participant anymore, but the file is still listed in the oc_mounts. |
Yes, the problematic user (user B in your example) is still in the room. |
|
Okay, then it might not be related at all. Thanks for checking! |
|
Thanks for the info! |
|
To be clear, this also happens on 24.0.7. So I think it is very important to fix this as soon as possible... |
|
In my case, User who shared the problem files to a conversation, was disabled about 6 months ago. He is still in the conversation for keeping links to his files in context conversation. |
|
Workaround for now: #34976 (comment) |
|
Finally managed to reproduce this one. The issue only occurs if some of the shares in a folder have an empty mount provider. If all they all have an empty mount provider the migration kicks in as expected. #35218 should fix it, please try applying the patch and see if it works for you |
szaimen
added
2. developing
|
@icewind1991 thanks a lot! Works in my case, missing shares are shown again in Talk folder! |
I can confirm, that this patch is working with 24.0.7, too. All the shares in the shared folder are back in action. Thank you! |
|
After applying the patch, collectives is not working anymore (folder '/Kollektive' cannot be accessed). After restoring the original SetupManager.php, Collectives works again and '/Kollektive' folder is accessible! @icewind1991 Can you have a second look??? UPDATE: |
|
We have the same problem following an update to 24.0.8. As it seems related, we are hit by:
It seems that the patch does not fix all the problems. |
|
We have found the cause of our errors. We had a share which had as uid_owner=user1 and share_whith=user1. This loop prevented the execution of the above patch, which led us in the wrong direction in the resolution of this incident. Sorry for the false alarm |
Bug description
After upgrading to NC 25 I noticed that shared files in talk could not be opened in web. After looking closer, I found that no files shared with me were visible in
/Talk.In
nextcloud.logI found the following:Looking at the database, this file had no
mount_provider_classset for my user, but was set for others:After setting the
mount_provider_classfor this file toOCA\Files_Sharing\MountProvideras well:The shared files were visible again for me in web. Also I am able to open files shared with me in talk-web again.
This issue was only present on web, I had no problems with the Files iOS app for example (every share was visible).
There are quite a few files which miss the
mount_provider_class:PROPFIND with user/passwort:
The same one from web returned only a size of 416672 (before the database change)
Steps to reproduce
/Talk)mount_provider_classto NULL for that file inoc_mountsExpected behavior
Files should be visible even if
mount_provider_classis not set.Maybe add a occ command to fix missing mount provider classes?
Installation method
Community Manual installation with Archive
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***" ], "trusted_proxies": "***REMOVED SENSITIVE VALUE***", "datadirectory": "***REMOVED SENSITIVE VALUE***", "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***", "htaccess.RewriteBase": "\/", "dbtype": "pgsql", "version": "25.0.0.18", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "mail_smtpmode": "sendmail", "mail_smtpauthtype": "LOGIN", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "25", "log_type": "syslog", "logtimezone": "Europe\/Berlin", "logfile": "", "loglevel": 0, "enabledPreviewProviders": [ "OC\\Preview\\PNG", "OC\\Preview\\JPEG", "OC\\Preview\\GIF", "OC\\Preview\\BMP", "OC\\Preview\\XBitmap", "OC\\Preview\\MP3", "OC\\Preview\\TXT", "OC\\Preview\\MarkDown", "OC\\Preview\\TIFF" ], "maintenance": false, "theme": "", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "memcache.distributed": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0, "timeout": 0 }, "preview_max_x": 1024, "preview_max_y": 1024, "preview_max_scale_factor": 1, "skeletondirectory": "", "updater.release.channel": "beta", "default_language": "de", "app_install_overwrite": [ "mindmap_app", "files_mindmap", "documentserver_community", "onlyoffice", "tasks", "polls", "previewgenerator", "forms", "issuetemplate", "spreed" ], "trashbin_retention_obligation": "auto, 30", "default_phone_region": "DE", "allow_local_remote_servers": true } }List of activated Apps
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: