Thank you for reporting this and for providing the workaround.
The following is a valid way to set the .NET polling variable from a .desktop launcher:
Exec=env DOTNET_USE_POLLING_FILE_WATCHER=1 /full/path/to/Manager-x86_64.AppImage
However, your example should use the full path to the AppImage. Exec=Manager-x86_64.AppImage works only if the file is in a directory included in the desktop session’s PATH. Otherwise, failure to start may be caused by the launcher not finding the AppImage, independently of the inotify issue.
A more complete launcher would therefore be:
[Desktop Entry]
Version=1.0
Name=Manager
Comment=Manager accounting software
Exec=env DOTNET_USE_POLLING_FILE_WATCHER=1 /home/username/Applications/Manager-x86_64.AppImage
TryExec=/home/username/Applications/Manager-x86_64.AppImage
Icon=/home/username/.local/share/icons/manager.png
Terminal=false
Type=Application
Categories=Office;Finance;
StartupWMClass=ManagerDesktop
The paths must be changed to the actual locations on your system. The AppImage must also be executable.
Please also check whether the workaround produces the same result when Manager is started directly from the terminal:
DOTNET_USE_POLLING_FILE_WATCHER=1 /full/path/to/Manager-x86_64.AppImage
That distinction is important. If the excessive inotify use also occurs when starting Manager normally from the terminal, and disappears when this variable is set, the issue is not specifically caused by the .desktop file. The .desktop file is then merely where you have applied the workaround.
The terminology that you use should also be corrected. The command you provided primarily counts “inotify watches” registered by processes, rather than “inotify handles” generally. Linux separately limits “inotify watches” and “inotify instances”. Please provide the output of:
cat /proc/sys/fs/inotify/max_user_watches
cat /proc/sys/fs/inotify/max_user_instances
cat /proc/sys/fs/inotify/max_queued_events
Please also state the Manager version. It would also be particularly useful to know the number of watches and whether the number reaches a stable level or continues increasing.
Your claim that most applications use only tens of watches should be removed. Applications that monitor complete directory trees can legitimately use hundreds or thousands. The issue here is whether Manager is unnecessarily monitoring a large number of paths or continually adding watches until the configured limit is reached!
The inotify-info utility is relevant for diagnosing this, but the report should contain the actual results rather than only linking to an external tool. In particular, identifying which directories ManagerServer is watching would help establish the underlying cause.
For now, DOTNET_USE_POLLING_FILE_WATCHER=1 appears to be a useful workaround on your installation. It does not yet establish that this is a general Ubuntu 26.04 problem or that launching Manager through a .desktop file is itself the cause.