[GROUP FOLDERS] Deleted files not being held in recycle bin

Nextcloud version (eg, 20.0.5): 23.0.3
Operating system and version (eg, Ubuntu 20.04): unraid 6.9.2
Apache or nginx version (eg, Apache 2.4.25): nginx/1.20.2
PHP version (eg, 7.4): 7.4.26

The issue you are facing:

I recently updated to nextcloud 23 and my recycle bin is now empty. I have previously had 365 days of retention, but now I can’t keep deleted files for more than a handful of minutes. I’m using 9.3TB of an available 37TB, so I don’t think it’s storage related. I can see the activity showing the file was created and deleted, but nothing is available when I click “Deleted Files”.

I’m at a loss for next steps in trying to figure out why this is happening.

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

Steps to replicate it:
(EDIT: This is only an issue with Group Folders for me)

  1. set trash retention in config.php 'trashbin_retention_obligation' => '365, auto',
  2. upload a new file, delete-test.txt
  3. delete file delete-test.txt
  4. file is visible when clicking the “Deleted Files” button
  5. wait a while (presumably until background jobs or cron is scheduled)
  6. check “Deleted Files”, nothing is available.

The output of your Nextcloud log in Admin > Logging:

includes sensitive data, will pm upon request

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

$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'filesystem_check_changes' => 1,
  'instanceid' => 'XXXXXXXXXXXXXXX',
  'trusted_domains' => 
  array (
    0 => '',
    1 => 'nextcloud.mydomain.com',
  'default_phone_region' => 'US',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'nextcloud',
  'dbhost' => '',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'xxxxxxxxxxxxxxxx',
  'dbpassword' => 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
  'installed' => true,
  'trusted_proxies' => 
  array (
    0 => 'letsencrypt',
  'overwrite.cli.url' => 'https://nextcloud.mydomain.com',
  'overwritehost' => 'nextcloud.mydomain.com',
  'overwriteprotocol' => 'https',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'mydomain.com',
  'mail_domain' => 'gmail.com',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'smtp.gmail.com',
  'mail_smtpport' => '465',
  'mail_smtpname' => 'xxxxxxxxxxxxxxxxxxx',
  'mail_smtppassword' => 'xxxxxxxxxxxxxxxxxxxxxxx',
  'app_install_overwrite' => 
  array (
    0 => 'groupfolders',
    1 => 'external',
    2 => 'theming_customcss',
    3 => 'audioplayer',
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'updater.secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'trashbin_retention_obligation' => '365, auto',
  'versions_retention_obligation' => 'auto, 90',

The output of your Apache/nginx/system log in /var/log/____:

/var/log/nginx/error.log is empty

take a look at the configuration of the trash folder. Depending on the settings and available space deleted file may be removed after short time already.

in config.php
'trashbin_retention_obligation' => '365, auto',

I’m using 9.3TB of an available 37TB, (28TB free)

# docker exec -it nextcloud occ trashbin:size --user=my_user
default (50% of available space)

This seems identical to #22475 but I don’t have an invalid trashbin size.

the discussion you referenced some users reported they had to configure server-wide trashbin size, did you test? please test with fix values as well, just to sort out the problem is somehow related to the assumed/determined free space

I’d rather not considering that the bug was supposedly fixed, and there’s currently no way to go back to a default percentage.


maybe… In my it works on NC23 (initially installed as NC19) - I see files deleted few day ago up to 1 year back in my trashbin. Maybe the problem is related to your /data mount point on shfs?

Doubtful. That’s a typical unRAID set up, and it’s been working for years. I’m also using group folders with unlimited quota. I’m guessing a bug regression having to do with one of those.

After doing some more testing, this appears to be limited to group folders

I wanted to suggest to check the bug tracker and report it there. But you have already done it:

Yes, I was hoping to keep the discussion going or figure out if anyone else is experiencing something similar.

Once it is considered a bug, the discussion moves to github. There others can share their environment as well in order to reproduce the bug for the developers.

I mean I consider it a bug, but until someone else can confirm the report, I can’t rule out that it’s an abnormality with my system. I would expect others would have experienced something similar by now.