> This can be solved with ACLs. Instead of creating a bind mount, this process
> that allows the user to share the directory can set an ACL and create a
> symlink.
For a few users maybe but not that easy when you have many thousands
users (that on top do not have local accounts). We'd probably h
> PS: if you maintain your own software and aren't able to find a way for your
> user to do shares - especially while systems that most likely have such
> functionality built-in out of the box surely exist, think Nextcloud etc -
> that is covered by how Linux is supposed to be used, by definitio
> 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.
>From my latest tests, it seems to point that way. Kernel 5.4 came with
a new mount API and it seems to break since then.
During my search,
> For this, probably the easiest is to set up a common directory/a few common
> directories, set up proper permissions through use of groups and worst case
> create some symlinks from the user's home directories, if these directories
> really need to be accessible from within their home director
> Does it really have to be in the home directory? Can't the software (and/or
> the users) open files in, say, /shared/accounting?
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 i
>> However do you need shared subtrees?
> I'm gonna test the effect of setting them to private.
This doesn't seem to fix the problem either
> Does it have some logic to avoid descending into bind mounts? Maybe I am
> wrong with my expectation that it does not use anything besides st_dev from
> stat result. It may be promising case to demonstrate the issue in a way
> independent of systemd and sandboxing. You can obtain command line
> Just to learn about it.
> What about using acl rather than bind mounts? What should be the
> problem in this solution?
As i said to Richard, rights are not the challenge here. It's to be
able to share a directory across multiple users. For instance you
would have : /users/bob/accounting shared w
> If there's a better way should be judged on what exactly that app expects.
> For the web interface, maybe the http server - or whatever makes the web
> interface accessible to the users - can limit permissions. For the rest of
> the use cases it would be interesting which circumstances would n
> Best question probably is: what exactly are you needing 14.000 mounts for?
> Even snaps shouldn't be that ridiculous. So what's your use case? Maybe
> there's a better solution to what you are doing. If it's just about having a
> place that is rw only without execution permissions, just crate
> What processes are CPU hungry?
On a vanilla debian 11 : udisksd, gvfs-udisks2-vo, (fstrim), find
> Perhaps it is not a Debian-specific bug, just more active usage of sandboxing
> in systemd. If some applications have troubles parsing /proc/mounts then bugs
> should be filed against them.
It
Dear,
Not sure i should report a bug so here is a report first. For more
than 10 years now, we've been using mount binds to create shares rw or
ro. It's been working perfectly under older Debian. A few months ago,
we migrated to Ubuntu Jammy and started having processes running 100%
non stop. Whil
12 matches
Mail list logo
