Software is only tested to a certain degree. So mounts are tested to a sensible number, if you move outside it, you have to bet on luck if it's supported or not. At this point, I kinda doubt this issue has anything to do with Debian itself, but will most likely be an issue/limitation of the Linux Kernel itself. So the biggest chance to get this fixed is compile the Kernel yourself ([1] is a great guide to do so with little to no effort, enabling and disabling all the same features Debian uses minus any potential additional patches. If it still occurs, you know it can't be a Debian problem. Try with both the sources of the Kernel version you use and the latest stable sources - 6.9.5 as of writing this. One thing though: replace make deb-pkg from the guide with make bindeb-pkg, and with -j# set a sensible number of concurrent jobs). If the issue still appears, head over to [2], see if someone else has reported a similar issue and if not, create a new bug report. This may be the only place to have the chance of getting a fix to ever be done, beyond hiring a service firm like Collabora etc and pay them for this specific thing.
Richard [1]: https://www.debian.org/doc//manuals/debian-handbook/sect.kernel-compilation.html [2]: https://bugzilla.kernel.org/ Am Do., 20. Juni 2024 um 00:06 Uhr schrieb Julien Petit <jul...@nethik.fr>: > You're thinking of a traditional file server in a business. Our > solution is a cloud platform. We don't know ahead how our customers > are going to manage their files and shares. And we don't need to. > As i said to Eduardo, it doesn't really matter where folders/mounts > are. Users can share any directory (and subdirectories) in their home > directory with any other user. The shared folder is mounted in the > special directory "Shared with me" of the recipient home directory. > I.e: John/Sales/Invoices is mounted in Alice/Shared with me/Invoices. > The shares can be read/write or read-only. >
