@@ -103,7 +103,12 @@ individually with the following options:
103103* Encryption
104104* Previews
105105* Enable Sharing
106- * Filesystem check frequency (Never, Once per direct access)
106+ * **Filesystem check frequency ** — controls how the server rescans an external
107+ storage path when a WebDAV ``PROPFIND `` request arrives for it.
108+ **Once per direct access ** makes a shallow rescans on each ``PROPFIND `` request;
109+ **Never ** skips the rescan entirely. This setting does *not * cause Nextcloud
110+ or desktop clients to poll automatically. See
111+ :ref: `external_storage_change_detection_label ` for details.
107112* Mac NFD Compatibility
108113* Read Only
109114
@@ -157,24 +162,105 @@ on your network!
157162.. figure :: external_storage/images/user_mounts.png
158163 :alt: Checkboxes to allow users to mount external storage services.
159164
160- Adding files to external storage
161- --------------------------------
165+ .. _external_storage_change_detection_label :
162166
163- We recommend configuring the background job **Webcron ** or
164- **Cron ** (see :doc: `../configuration_server/background_jobs_configuration `)
165- to enable Nextcloud to automatically detect files added to your external
166- storages.
167+ Detecting changes made outside Nextcloud
168+ -----------------------------------------
167169
168- Nextcloud may not always be able to detect changes made remotely (files changed without going through Nextcloud), especially
169- when files are located deep in the folder hierarchy of the external storage.
170+ When files are added, modified, or deleted on an external storage **directly **
171+ (without going through Nextcloud), Nextcloud will not know about those changes
172+ immediately. Nextcloud maintains an internal index (the *filecache *) that is only
173+ updated when Nextcloud itself performs a scan. Until that scan happens, the
174+ filecache is stale and the changes are invisible to Nextcloud, desktop clients,
175+ and mobile apps.
170176
171- You might need to set up a cron job that runs ``sudo -E -u www-data php occ files:scan --all ``
172- (or replace ``--all `` with the username; see also :doc: `../occ_command `)
173- to trigger a rescan of the user's files periodically (for example, every 15 minutes), which includes
174- the mounted external storage.
177+ How the "Filesystem check frequency" option works
178+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
175179
176- If you are running Nextcloud AIO, the equivalent command
177- in that environment is ``sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ files:scan --all ``.
180+ The **Filesystem check frequency ** mount option (see
181+ :ref: `external_storage_mount_options_label `) controls what happens when a WebDAV
182+ ``PROPFIND `` request reaches the Nextcloud server for a path inside the external
183+ storage:
184+
185+ * **Once per direct access ** — during ``PROPFIND `` requests made to a given directory,
186+ Nextcloud rescans that directory level then updates the filecache with what it finds there.
187+ * **Never ** — the server never rescans the external storage during ``PROPFIND `` requests
188+ and always returns the content stored in its internal index.
189+
190+ This option is *only * about the server's behavior during a ``PROPFIND ``. It does
191+ not trigger any background polling and does not change how desktop clients or
192+ mobile apps behave.
193+
194+ Because this rescan is driven by user actions (opening a folder in the web UI,
195+ browsing in the mobile app, or a client issuing a ``PROPFIND ``), change detection
196+ remains random and unreliable for deep folder hierarchies.
197+
198+ Why desktop clients miss deep changes
199+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
200+
201+ The desktop sync client only issues a ``PROPFIND `` on the root of the sync folder
202+ on every sync cycle because scanning the entire tree would be too expensive. It
203+ relies on **etag propagation **: when a file changes, the etag of every parent
204+ folder up to the root must also change, giving the client a trail to follow down
205+ to the changed file.
206+
207+ When a change is made outside Nextcloud, no etag is updated. The client sees no
208+ trail from the root and never follows it down to the changed file.
209+
210+ How to make external changes reliably detectable
211+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
212+
213+ There are two approaches, depending on the storage type:
214+
215+ **A) SMB/CIFS storages — use update notifications **
216+
217+ The ``files_external:notify `` command listens for change events sent by the SMB
218+ server itself. When a change event arrives, Nextcloud rescans the affected path
219+ and propagates the etag changes up to the root, so desktop clients pick up the
220+ change on their next sync cycle.
221+
222+ .. code-block :: console
223+
224+ occ files_external:notify <mount_id>
225+
226+ See :doc: `external_storage/smb ` for setup details, including authentication
227+ requirements and how to reduce sync delay.
228+
229+ **B) All other storages — periodic rescan via cron **
230+
231+ For storage types that do not support push notifications, set up a cron job that
232+ rescans the external storage periodically using its mount ID:
233+
234+ .. code-block :: console
235+
236+ sudo -E -u www-data php occ files_external:scan <mount_id>
237+
238+ You can find the mount ID with ``occ files_external:list ``. See
239+ :doc: `../occ_command ` for the full ``files_external:scan `` reference. A typical
240+ interval is every 15 minutes; adjust to balance freshness against server load.
241+
242+ .. note ::
243+ If you are running Nextcloud AIO, the equivalent command is:
244+
245+ .. code-block :: console
246+
247+ sudo docker exec --user www-data -i nextcloud-aio-nextcloud php occ files_external:scan <mount_id>
248+
249+ Limitation: renames are not detected reliably
250+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
251+
252+ Whenever Nextcloud rescans an external storage — whether via periodic cron
253+ (option B) or via the **Once per direct access ** filesystem check frequency setting —
254+ the scanner cannot reliably detect that an entry was **renamed **. It sees the old
255+ name as deleted and the new name as a newly created entry. This causes
256+ **metadata loss **: all shares, tags, comments, and activity history associated
257+ with the old entry are permanently deleted from Nextcloud's database.
258+
259+ .. warning ::
260+ If users rename files or folders directly on the external storage (outside
261+ Nextcloud), that metadata loss is unavoidable. To preserve metadata, all renames
262+ should be done through Nextcloud itself, or — for SMB — use update notifications
263+ (option A) which handles renames via the SMB change event stream.
178264
179265.. _trouble-file-encoding-ext-storages :
180266
0 commit comments