On 19/06/2024 16:27, Julien Petit wrote:
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 sandboxi
Julien Petit wrote:
> How Linux is supposed to be used? That's why i'm here. There wasn't
> until kernel 4.19 an official limit to the number of mounts in the
> documentation. Even though we use mounts a lot, we're still far from
> the official limit. Did we get lucky for 15 years and we should ch
> 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,
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 definition
it's pret
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 K
On 19/06/2024 19:06, Julien Petit wrote:
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:
> 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
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 directories. That's
On 19/06/2024 05:46, Julien Petit wrote:
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 with Alice
and accessible in her home directory /users/alice/accounting
Does it really have to be in
> 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
On 14/06/2024 16:30, Julien Petit wrote:
What processes are CPU hungry?
[...]
udisksd,
This one does not use mount namespace for the obvious reason. However it
tends to generate unnecessary activity. Perhaps it needs optimizations
for your case.
(fstrim)
There were some bugs including
El Fri, 14 Jun 2024 11:30:50 +0200
Julien Petit va escriure el següent:
> > 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 applicat
On 14.06.24 11:38, Julien Petit wrote:
We use the mounts to share an initial folder with either rw or ro
wrights in a user directory. The user directory is then accessible
through a web interface, sftp, webdav and rsync. There is probably
better ways to do that now but that's a legacy app (2009)
> 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
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 a
separate
On 12/06/2024 17:02, Julien Petit wrote:
for i in {1..14000}
do
echo "Mounting dir $i"
mkdir "/home/test/directories/dir_$i"
mkdir "/home/test/mounts/dir_$i"
mount --bind -o rw "/home/test/directories/dir_$i"
"/home/test/mounts/dir_$i"
done
After that, the "top" command will sho
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
24 matches
Mail list logo
