Bug Report: Auto Upload rules only scan on creation — no ongoing folder monitoring

[robdupas-svg]

⚠️ Before posting ⚠️

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

1. Set up an Auto Upload rule (either the app's auto-generated "Camera" rule, or a manually created custom folder rule) pointing at a device folder
2. Confirm any existing files in that folder upload successfully (initial scan works)
3. Take a new photo and save it into the same watched folder
4. Wait — do not touch the app or the rule in any way
5. Observe: the new photo is never uploaded, queued, or shown in the Uploads screen
6. Try opening the app, rebooting the device, or disabling/re-enabling the rule (without deleting it) — none of these trigger a scan
7. Delete the rule entirely and create a new one pointing at the same folder — the pending photo uploads immediately

Expected behaviour

New files added to a folder with an active Auto Upload rule should be detected and uploaded automatically on an ongoing basis, without requiring the rule to be deleted and recreated each time.

Actual behaviour

Auto Upload rules only perform a file scan at the moment the rule is created. After that, the rule appears active/enabled but never detects new files — no error, no queue entry, no notification. This was tested across many repeated cycles (disable/enable, app open/closed, device reboot) with 100% consistent results: only deleting and recreating the rule re-triggers a scan.

Environment and everything ruled out (permissions, battery/background restrictions, install source, corrupted local state, third-party app interference) detailed below.

Related issues: found similar reports (#16679, #14931, #16334) describing auto-upload silently failing or settings resetting, but none isolate this specific trigger — that rule creation specifically causes a scan, while toggling an existing rule never does.

Bug Report: Auto Upload rules only scan on creation — no ongoing folder monitoring

Summary

Auto Upload rules (both the app's auto-generated "Camera" rule and manually created custom folder rules) only detect and upload files at the moment the rule is created. After that initial scan, the rule becomes inert — it never picks up new files added to the watched folder afterward, regardless of app state, device reboots, or manual retry actions. The only way to trigger another scan is to delete the rule and create a new one.

This was isolated through a methodical, multi-hour testing session that ruled out every plausible environmental cause (Android permissions, HyperOS battery/background restrictions, install source, corrupted local state, third-party app interference) before landing on a clean, 100%-reproducible pattern tied specifically to rule creation events.

Environment

• Device: Xiaomi 12 Lite, HyperOS 1.0.34.0, Android 14
• Nextcloud server: self-hosted, Nextcloud 34, Apache/MySQL/PHP LAMP stack, reached via Cloudflare Tunnel
• App versions tested: Nextcloud Android Client from both F-Droid and Google Play Store — identical behavior on both
• Control device (for comparison): same household, Xiaomi 11 Lite, Android 11 — auto upload works reliably with only "Photos and Videos" permission granted, no other configuration

What was ruled out (with evidence)

Suspect	Test performed	Result
Android 13+ granular media permission	Set explicitly to "Allow all"	No change
Battery optimization	Set to "No restrictions"	No change
Autostart	Confirmed enabled	No change
"Allow restricted settings" (Android 13+ install-trust flag, relevant to F-Droid installs)	Confirmed enabled	No change
Notification permission	Confirmed granted	No change
Corrupted local app state / stale rule references	Full uninstall, wiped DCIM/Pictures/WhatsApp media folders including hidden .thumbnails caches, rebooted, reinstalled clean	Problem persisted on a genuinely fresh install with brand-new photos
Server-side issue	Uploaded the same stuck file successfully via Nextcloud web UI directly; tailed nextcloud.log on the server while triggering an app upload — no request ever arrived	Confirms server was never the bottleneck
Install source (F-Droid vs. Play Store)	Full clean test on both	Identical failure pattern on both
Third-party app interference (SHAREit)	Found a stray .shareit_beyla_ids metadata file recreating itself in the watched folder from a leftover (uninstalled) SHAREit data folder at device root; deleted the leftover folder entirely	File stopped recreating, but core upload bug was unaffected
MIUI/HyperOS background process optimization	Not fully tested (requires Mi account credentials not readily available), but ruled out as the sole explanation given results below	N/A

The actual reproducible pattern

Once permissions, install state, and third-party interference were eliminated, the following sequence was run repeatedly and produced the same result every time:

1. Create or re-enable-via-delete-and-recreate a rule (either the auto-generated Camera rule or a manually created custom folder rule) → any existing files in the folder upload immediately.
2. Take a new photo while an existing, already-created rule is active (app open or closed, doesn't matter) → nothing happens. No queue entry, no error, no retry, no notification.
3. Reboot the phone → does not restore functionality. Opening the app afterward does not trigger a scan.
4. Disable and re-enable the same rule (without deleting it) → does not trigger a re-scan. No upload occurs.
5. Delete the rule and create a brand-new one pointing at the same folder → the pending photo uploads immediately, every time, no exceptions.

This was repeated across many cycles with consistent results — disable/enable never worked, delete/recreate always worked.

Conclusion

This points to a specific, narrow bug rather than general background-service flakiness: the app's folder-watching/detection logic is only invoked in the rule-creation code path (i.e., whatever mechanism registers a FileObserver, ContentObserver, or scheduled WorkManager job for a folder is tied to rule creation, and is never re-registered on app launch, device boot, or rule enable/disable). Because the failure is deterministic and precisely reproducible around rule creation specifically — rather than intermittent — this behaves like an application logic bug, not an OS-level background restriction (which would typically produce inconsistent, timing-dependent failures rather than a clean 100%-reproducible pattern).

This matches several existing reports in the nextcloud/android issue tracker describing auto-upload silently failing to notice new files after working initially, settings/state not surviving reboots or updates, and an active ongoing debug thread (#16550 / #16679) investigating upload failures with logs showing uploads getting stuck or timing out after being queued.

Feature request (related, separate ask)

Independent of the bug above: there is currently no way to prevent the app from auto-scanning device storage and auto-generating Auto Upload rules (e.g., "Camera", "WhatsApp") on first setup. During this troubleshooting session, auto-generated rules were repeatedly found to reference stale or broken folder links that persisted across disable/re-enable and rule recreation, and the only way to reach a clean state was full uninstall + manual deletion of all matching media folders (including hidden cache folders) + reinstall.

Request: add an option (ideally presented at first launch, before any folder scanning occurs) to skip auto-detection/auto-rule-generation entirely, so users can add only the folders they explicitly choose.

Suggested next steps for maintainers

• Logcat capture of a failed "new photo added to already-existing rule" event would show whether the file-change event is even received by the app (adb logcat | grep -i nextcloud)
• Worth checking whether FileObserver/ContentObserver registration in the codebase is scoped only to rule-creation flow vs. also being re-established on BOOT_COMPLETED and app process start
• Reproducible test case above should be straightforward to verify on any Android 13+ device, not device-specific

Android version

Android 14

Device brand and model

Xiaomi 12 Lite

Stock or custom OS?

Stock

Nextcloud android app version

Version 34.1.0

Nextcloud server version

Nextcloud server version: 34.0.1 (Nextcloud Hub 26 Spring)

Using a reverse proxy?

Yes

Android logs

No client-side logcat captured at time of writing.

Server error logs

Server-side nextcloud.log was tailed live during testing — confirmed no request reaches the server when a new file fails to upload under an existing (non-recreated) rule, which is consistent with the app never attempting the upload rather than a network/server-side failure. Happy to capture logcat output on request if it would help (adb logcat | grep -i nextcloud during a reproduction).

Additional information

No response

[robdupas-svg]

please note: similar symptoms reported as far back as 2020-2021, suggesting this may be long-standing rather than a recent regression

[alperozturk96]

Hey,

Thank you for the report.

Could you please also test via latest QA APK and share your feedback?

#17401