⚠️ This issue respects the following points: ⚠️
Bug description
When using S3-compatible primary storage, file uploads via Nextcloud Talk (Android) result in files being stored as 0 B in Nextcloud metadata, although the actual object is correctly uploaded to S3.
This issue does not occur in Nextcloud 30.0.16 and appears to be a regression starting from Nextcloud 30.0.17.
The problem is reproducible across multiple versions (30, 31, 32, 33).
Steps to reproduce
- Configure S3-compatible storage as primary storage
- Open Nextcloud Talk on Android
- Upload a file (image, video, etc.)
- Check uploaded file in Nextcloud Web UI
Result:
Additional verification:
- The object exists in S3 and has the correct size
- Only metadata (filecache.size) is incorrect
Expected behavior
File size stored in Nextcloud (oc_filecache.size) should match the actual object size stored in S3.
Nextcloud Server version
32
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 32.0.1 to 32.0.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
{
"system": {
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"xxx.xx.xxx.xx",
"test-system.org"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"objectstore": {
"class": "OC\\Files\\ObjectStore\\S3",
"arguments": {
"bucket": "hana-nc-storage-bk20251101",
"autocreate": true,
"region": "ap-northeast-1",
"key": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"use_ssl": false,
"use_path_style": true
}
},
"dbtype": "mysql",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"loglevel": 2,
"mail_smtpmode": "smtp",
"mail_smtptimeout": 10,
"mail_sendmailmode": "smtp",
"mail_smtpauthtype": "LOGIN",
"mail_smtpauth": 1,
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"mail_smtpsecure": "ssl",
"memcache.local": "\\OC\\Memcache\\APCu",
"instanceid": "***REMOVED SENSITIVE VALUE***",
"auth.bruteforce.protection.enabled": false,
"overwrite.cli.url": "http:\/\/xxx.xxx.xxx.xxx",
"overwritehost": "test-system.org",
"overwritewebroot": "\/",
"overwritecondaddr": "^xxx\\.xxx\\.xxx\\.xxx$",
"forcessl": true,
"overwriteprotocol": "https",
"version": "30.0.17.2",
"installed": true,
"default_language": "ja",
"default_phone_region": "JP",
"maintenance": false,
"allow_user_to_change_display_name": true,
"theme": "",
"trashbin_retention_obligation": "auto, 7",
"app_install_overwrite": [
"spreed",
"talk_matterbridge",
"talked",
"richdocuments"
],
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"maintenance_window_start": 1
}
}
List of activated Apps
Enabled:
- activity: 3.0.0
- app_api: 4.0.6
- appointments: 2.4.6
- bruteforcesettings: 3.0.0
- calendar: 5.5.9
- cloud_federation_api: 1.13.0
- comments: 1.20.1
- contacts: 7.3.7
- contactsinteraction: 1.11.0
- dashboard: 7.10.0
- dav: 1.31.1
- deck: 1.14.7
- drawio: 3.0.9
- external: 5.5.2
- federatedfilesharing: 1.20.0
- federation: 1.20.0
- files: 2.2.0
- files_accesscontrol: 1.20.4
- files_automatedtagging: 1.20.1
- files_downloadlimit: 3.0.0
- files_external: 1.22.0
- files_linkeditor: 1.1.23
- files_pdfviewer: 3.0.0
- files_reminders: 1.3.0
- files_retention: 1.19.1
- files_sharing: 1.22.0
- files_trashbin: 1.20.1
- files_versions: 1.23.0
- firstrunwizard: 3.0.0
- forms: 5.2.3
- impersonate: 1.17.1
- integration_openai: 3.9.1
- logreader: 3.0.0
- lookup_server_connector: 1.18.0
- mail: 5.5.15
- nextcloud_announcements: 2.0.0
- notes: 4.12.4
- notifications: 3.0.0
- oauth2: 1.18.1
- password_policy: 2.0.0
- privacy: 2.0.0
- provisioning_api: 1.20.0
- recommendations: 3.0.0
- related_resources: 1.5.0
- richdocuments: 8.5.12
- richdocumentscode: 25.4.702
- serverinfo: 2.0.0
- settings: 1.13.0
- sharebymail: 1.20.0
- spreed: 20.1.10
- support: 2.0.0
- survey_client: 2.0.0
- systemtags: 1.20.0
- talk_matterbridge: 1.31.1026000
- talked: 0.5.0
- tasks: 0.16.1
- text: 4.1.0
- theming: 2.6.0
- twofactor_backupcodes: 1.19.0
- updatenotification: 1.20.0
- user_status: 1.10.0
- viewer: 3.0.0
- weather_status: 1.10.0
- webhook_listeners: 1.1.0-dev
- workflowengine: 2.12.0
Disabled:
- admin_audit: 1.20.0
- announcementcenter: 6.6.2 (installed 6.6.2)
- circles: 30.0.0 (installed 25.0.0)
- encryption: 2.18.0
- files_antivirus: 5.6.1 (installed 5.6.1)
- files_rightclick: 0.15.1 (installed 1.6.0)
- fulltextsearch: 25.0.0 (installed 25.0.0)
- health: 1.6.1 (installed 1.6.1)
- imageconverter: 1.3.2 (installed 1.3.2)
- photos: 3.0.2 (installed 1.6.0)
- suspicious_login: 8.0.0
- twofactor_email: 2.7.4 (installed 2.7.4)
- twofactor_nextcloud_notification: 4.0.0
- twofactor_totp: 12.0.0-dev
- user_ldap: 1.21.0
- user_usage_report: 1.6.0 (installed 1.6.0)
Nextcloud Signing status
Nextcloud Logs
Additional info
Affected versions
- 30.0.17 /
- 31
- 32
- 33.0.1 RC2
Not affected
- 30.0.16 (works correctly)
Clients
- Android Talk: affected
- iOS Talk: works
- Web upload: works
Findings
- Upload to S3 succeeds (object exists with correct size)
- oc_filecache.size is recorded as 0
- Metadata inconsistency occurs after upload
Example:
SELECT fileid, size FROM oc_filecache WHERE fileid = <affected_file>;
→ size = 0
Additional investigation
- Fixed FileSequence (temp/cron not writable) issue, but problem persists
- Therefore not caused by filesystem permission alone
Possible cause
Issue in ObjectStoreStorage or size reconciliation logic after upload
Workaround
Applying a local patch to size reconciliation logic prevents new uploads from becoming 0 B
Related discussion
https://help.nextcloud.com/t/android-talk-upload-results-in-0-b-files-when-using-s3-primary-storage-on-nextcloud-31-0-9-and-31-0-10-works-fine-on-30-0-16/235255
Bug description
When using S3-compatible primary storage, file uploads via Nextcloud Talk (Android) result in files being stored as 0 B in Nextcloud metadata, although the actual object is correctly uploaded to S3.
This issue does not occur in Nextcloud 30.0.16 and appears to be a regression starting from Nextcloud 30.0.17.
The problem is reproducible across multiple versions (30, 31, 32, 33).
Steps to reproduce
Result:
Additional verification:
Expected behavior
File size stored in Nextcloud (oc_filecache.size) should match the actual object size stored in S3.
Nextcloud Server version
32
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 32.0.1 to 32.0.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
{ "system": { "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "localhost", "xxx.xx.xxx.xx", "test-system.org" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "objectstore": { "class": "OC\\Files\\ObjectStore\\S3", "arguments": { "bucket": "hana-nc-storage-bk20251101", "autocreate": true, "region": "ap-northeast-1", "key": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "use_ssl": false, "use_path_style": true } }, "dbtype": "mysql", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "loglevel": 2, "mail_smtpmode": "smtp", "mail_smtptimeout": 10, "mail_sendmailmode": "smtp", "mail_smtpauthtype": "LOGIN", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "465", "mail_smtpsecure": "ssl", "memcache.local": "\\OC\\Memcache\\APCu", "instanceid": "***REMOVED SENSITIVE VALUE***", "auth.bruteforce.protection.enabled": false, "overwrite.cli.url": "http:\/\/xxx.xxx.xxx.xxx", "overwritehost": "test-system.org", "overwritewebroot": "\/", "overwritecondaddr": "^xxx\\.xxx\\.xxx\\.xxx$", "forcessl": true, "overwriteprotocol": "https", "version": "30.0.17.2", "installed": true, "default_language": "ja", "default_phone_region": "JP", "maintenance": false, "allow_user_to_change_display_name": true, "theme": "", "trashbin_retention_obligation": "auto, 7", "app_install_overwrite": [ "spreed", "talk_matterbridge", "talked", "richdocuments" ], "passwordsalt": "***REMOVED SENSITIVE VALUE***", "maintenance_window_start": 1 } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Affected versions
Not affected
Clients
Findings
Example:
SELECT fileid, size FROM oc_filecache WHERE fileid = <affected_file>;
→ size = 0
Additional investigation
Possible cause
Issue in ObjectStoreStorage or size reconciliation logic after upload
Workaround
Applying a local patch to size reconciliation logic prevents new uploads from becoming 0 B
Related discussion
https://help.nextcloud.com/t/android-talk-upload-results-in-0-b-files-when-using-s3-primary-storage-on-nextcloud-31-0-9-and-31-0-10-works-fine-on-30-0-16/235255