Applies to: Umango deployments running on Linux, inside Docker containers, or under Windows Subsystem for Linux (WSL), where a Watched Folder source is used to pick up incoming documents.
A Watched Folder that works perfectly on Windows may appear to do nothing when the same configuration is run on Linux or WSL. Files dropped into the folder are never picked up, and no error is reported. This is not a fault in the folder configuration. It is caused by a difference in how each operating system tells an application that a file has arrived.
To enable Umango to process files as soon as they arrive in a folder when they are running in Job Services, Umango asks the operating system to tap it on the shoulder the moment a file appears. This "shoulder tap" service is built into the operating system, and each platform implements it differently.
On Windows, this notification service is happy to report changes even when the folder lives on a network share. That is why watched folders on mapped drives and UNC paths generally just work on a Windows host.
On Linux, the equivalent service (known as inotify) is stricter. It only reports changes that happen on a genuine local disk, on the same machine. If the folder is not truly local, the notification never fires, so Umango is never told a file has arrived and simply keeps waiting. The folder is readable and everything looks correct, but the "tap on the shoulder" never comes.
A folder counts as "not truly local" in more situations than you might expect:
/mnt/c, /mnt/d, and so on. These are not real Linux disks. They are a bridge into the Windows filesystem, and change notifications do not cross that bridge. A folder such as /mnt/c/Users/You/Incoming will never notify Umango, even when a Windows application drops a file straight into it.Choose the option that best fits where the documents actually come from.
If the folder can live anywhere, place it on the Linux filesystem itself rather than on a mount or share. On a standard Linux host or container this means a normal local path. Under WSL this means a path inside the Linux home area, for example /home/umango/incoming, rather than anything under /mnt/c. Notifications work normally here, and file access is also noticeably faster.
If the folder genuinely has to stay on a network share or on the Windows side of WSL, your files will eventually get picked up. Umango also uses a polling model where the folder is re-checked on a schedule rather than waiting for a live notification. Polling does not depend on the operating system notification service, so it is unaffected by shares and bridges. The trade-off is a small, configurable delay between a file arriving and being picked up. By default, the wait time can be significant - usually > 30 mins. However, you can reduce this to any time in 1 minute increments down to even 1 minute. To do this set the value of Umango.Addin.Import.Folder.InactivityCheckMinutes to a value such as 3 (to force checking every 3 minutes).
If you watch a folder and all of its subfolders on Linux, each subfolder consumes one notification slot, and Linux caps how many slots are available. Very large or deeply nested folder trees can quietly exhaust this cap, causing deeper folders to stop reporting changes. A system administrator can raise the limit by increasing fs.inotify.max_user_watches. In a container this is set on the host, because it is a machine-wide kernel setting. This only matters once the folder is on native Linux storage. On a share or a /mnt/c path, no amount of extra slots will help.
A quick test will confirm whether the notification boundary is the problem:
/mnt/c and not on a share).If the test folder picks the file up but the original folder does not, the original folder is on a share or a bridge, and one of the resolutions above applies. If neither folder picks anything up, contact Umango support, as the cause is something else.