Server: Can't Delete Files from Group Folders

[circlenaut]

Steps to reproduce

1. Create a group folder
2. Delete file from within group folder

Expected behaviour

File to be deleted/moved to trashbin

Actual behaviour

Error thrown "Error deleting file "filename".

Many entries for "Could not find mount point, can't keep encryption keys" in the log.

According to issues 177 and 53 this should be resolved in NC15. Any thoughts on how to fix this? How to disable encryption for group folders?

Server configuration

Operating system:
Ubuntu 16.04.5
Web server:
Apache 2.4.18
Database:
Mariadb 10.1
PHP version:
7.2.13-1
Nextcloud version: (see Nextcloud admin page)
15
Updated from an older Nextcloud/ownCloud or fresh install:
Updated from 14 (which was updated from 13)
Where did you install Nextcloud from:
WebGUI

[Henk57]

Same issue here. Already with NC 14. Now updated to NC 15.
If I delete a folder in a group folder it shows up again after refreshing.
But in fact this folder is no longer viable with FileZilla, so it is actualy deleted.

Thought the tables were messed up. S I ran mentioned updates to do:
occ db:convert-filecache-bigint
occ db:add-missing-indices

No effect. I ran:
occ files:scan --all
occ: maintenance:repair --all
occ:files cleanup
occ:trashbin:cleanup

And still those 3 folders in a Group folder are in the webbrowser. Also with WebDAV. But NOT in FTP view.

Clicking on the Share icon at the right in the browser sets the system in a sort of endless loop. So there are inconsistencies.

The log of occ files:scan --all shows that GROUP folders are not checked, as far as I can understand. Only the normal user folders are checked for repair.

I manualy added the 'deleted' folder again with FTP. It shows up in the browser as 'added 3 minutes ago'.
I deleted that folder again in the browser. It is gone with FTP, but after a browser refresh it is in the browser visible again.

So my conclusion: File management in GROUP folders does not work as expected. Delete does not work, and occ functions do not include GROUP folders.

[circlenaut]

Ran commands that Henk57 suggested. No dice, same issue. Upgraded to 15.02 manually. Again, no dice.

[Henk57]

The command occ:trashbin:cleanup does not seem to work at all. None of the files in the trash seem to be removed.
If I remove the contents through the webbrowser, all files and maps in the trash have been deleted.
But after a screen refresh the deleted (empty) folder that came from the Groupsfolder is back again, in the trash AND as a normal folder in the Groupsfolder.

So it seems that occ commands do not work properly too.

This problem seems to be related to that in https://github.com/nextcloud/groupfolders/issues/242

In that item all the problems with deleting files seem to be related to Groupfolders plugin. And that is an official plugin.

[rzerres]

Same problem here!

[rzerres]

Is there any manual/scripted way to delete Groupfolder files until the root-problem is solved?
Otherwise users will flood the filesystem without a chance to cleanup. As soon as shares are involved (eg. auto remove expiration dates) it gets realy nasty.

Right now (v15.0.2.0) you can install, upload, view files. As soon as you try to delete them,
you will recieve the already described error message https://github.com/nextcloud/server/issues/13380#issue-396147155

[GuidoDr]

same problem here with 15.0.2 :-(
Even files that were uploaded a minute ago cannot be deleted from the group folders

[srgvg]

I'm experiencing this, too. It al started with upgrading to NC15, and having issues with my primary storage being on S3 - see #13062.

Right now, I'm encountering this Could not find mount point, can't keep encryption keys error with both files & folders that should be deleted on the server, or with new files that don't get uploaded.

A relevant part of the server log can be found here: http://paste.debian.net/1062994/ - this is about files that can't get deleted.

Another part of log file is http://paste.debian.net/1062995/ - which is actually about a local file that won't get uploaded (even the log mentions deleting it...)

I can also confirm this issue seems to only happen with Group Folders

I tried looking at the occ:files and occ:maintenance commands, but I get the feeling those only work with local files, not S3 as primary storage? At least occ:files commands return 0 files processed.

[Henk57]

Look at my other comments, also in nextcloud forum.

Encryption does not work 'by design' for group folders. That is in the comments with this app.

In my opinion, do not use groupfolders but create a user 'groupsuser' or so. Then share from that account. This works with encryption too.

[srgvg]

Thanks for your feedback @Henk57. Going back and not using group folders is not a practical option at this point.

But, to be clear, I'm not using encryption. According to the issue in #13062, the encryption module needs to be installed and enabled, but does not need to be active, as in, encryption as a feature needs not to be enabled. That was basically the workaround I was told to implement, just enabling the app, not enabling encryption.

[Henk57]

Here https://github.com/nextcloud/groupfolders/issues/290 I've made a list of actions that worked in my situation.
I've never had 'encryption failure' errors with Nextcloud.

[srgvg]

The encryption mentioning error is the main issue I encounter. There have been reports of this not being encryption related, but an artefact of the underlying bug. Either way, sounds like you have another issue than me.

[GuidoDr]

error remains also in NC 15.0.4

[GuidoDr]

I got it solved by completely uninstalling the default encryption module of Nextcloud.
(I deleted the encryption directory and all its files and subdirectories in the nextcloud/apps directory even though we did not use the encryption)
Not really a preferred solution to delete a default app only to get another app working again. 👎

[small1]

I can confirm this bug in 15.0.4. We have files in a groupfolder that after deletion shows up again. It is not removed from the filesystem.
roup
A few more tests will be performed. Steps to reproduce that we found:

1. Create a groupfolder and give a group A access to it
2. Create a subfolder in that group and share it with Group B
3. Person in group b creates a file
4. Person in group b deletes the file

Expected behavior: the file should be deleted.
Current behavior: the file is still in the filesystem and shows again in the webui after refresh

[small1]

Did some additional tests. For me it affects shared subfolders of a groupfolder. Users not it the groupfolder group cant delete files.

[assysttest]

Problem has been changed on Nextcloud 16.0.3.0, Group folders 4.0.4
Following happens:
1) create a group folder with a single file
2) delete the file
3) open the trash bin, delete the file permanently. The file becomes invisible, even on refresh (new in group folders 4.0.4, in the past it appears again)
4) check the content of nextcloud data directory, __groupfolders/trash. A corresponding directory is not deleted.

[bositman]

Can confirm it still happens as described above in:
Nextcloud 16.0.3
Group folders 4.0.5
This should be of critical priority...

[gvansanden]

Another issue with groupfolders... I'm so sorry that I started using them.
No activity log, sync issues when users delete files or folders that others have synced and now this.

[gvansanden]

Instead of using scan (which is too slow), the only viable workaround seems to delete on the fs and remove from the database.

[UkeFan]

Is it solved by now? Somehow group folders seem to be a must if one uses NC with many users or ist the alternative to uncheck the "may delete" option in all users sharing options?!

[skjnldsv]

Unfortunately no update so far

[apg1980]

Nextcloud 18.04 the issue still exists.

[herbetom]

I'm not certain if that is related to this issue, but i have the problem that if i want to empty the Trashbin completely and i mark at the top all files and then say "Delete Permanently" (if that's the correct translation - i'm using nextcloud in German) it will empty the Trash without an an animation or something like that and on a page reload the files are shown again.

I'm using Group Folders for evertyhing in that NC instance. So all Files in the Trashbin are Group Files.

A workarround i found is to mark all files and then uncheck one single file. If i then say "Delete Permanently" it will show an animation of the files disappearing one by one and also on reload they aren't shown again.

I'm currently using Nextcloud 18.0.4

[andrenasturas]

Nextcloud 19.0 ant the issue still exists. Also deleting encryption app seems to have no effect on the issue.

Current behaviour on my installation :

• Deleting a file in a group folder in the web interface seems to work only until I refresh the page, The file is still there. It is marked as deleted in its Activity thread.
• Deleting a file in a group folder in the file explorer causes an error shown by the Nextcloud synchronisation client as "HTTP 204 expected, 200 OK received instead". The file does not shows up again in the file explorer, but it is still there in Nextcloud web interface.

[DBJRdev]

Problem exists here as well, and it's getting problematic as the server harddisk gets full:
NC 18.0.7 (fresh install last November) with always most recent version of groupfolders app, PHP 7.3, MySQL 5.7

[assysttest]

For me it becomes a real problem: we use nextcloud group folders in a school and some files containing personal data of childrens. It's a legal issue to delete this during the summer holidays. Unfortunately it's impossible without some tricks.

[TFA-N]

This issue is still happening and still a problem.

[benhartwich]

New major release and no progress on the basic file features. How should we use nextcloud in bigger environments when there is no progress on this important issue?

[c-s-w]

It's a problem of the groupfolders app, not the Nextcloud core. The app does not react on the "delete all" event, so the workaround is to select all files but one - then it's possible to permanently delete files in the trash. See https://github.com/nextcloud/groupfolders/issues/314 for details.