Folder permissions are inconsistent when using {u}

[Sirmentio]

Describe the bug
Running a local (not docker) copyparty-sfx. In my configuration folder, I have the following:

[/${u}]
	./${u}
	accs:
		g: *
		rwmd: ${u}, @su
	flags:
		vmaxb: 1g

However, no one outside of the user who owns the folder can see/get anything from it. Not even su members, which telling form above should have the same permissions as the user.

Expected behavior
Everyone should be able to get, guests/strangers, other users alike, what's inside of the volumes. su group members should be able to access these files as well.

Server details
if the issue is possibly on the server-side, then mention some of the following:

• server OS / version: 6.1.0-1-amd64 pypy3 bug #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64 GNU/Linux
• python version: Python 3.11.2
• copyparty arguments: --no-robots -c /opt/copyparty/copyparty.conf
• filesystem (lsblk -f on linux): ext4

Additional context
I've been trying to get this to work for a bit. Irritatingly, permissions works as expected if I manually make the volumes in the config, by hand. This can be a workaround for now, but I would prefer to have less work in the long run (And even less so if I bother with Oauth 😉)

[9001]

Hey! thanks for the heads-up, and for trying copyparty :>

I'll take a look this weekend, just gotta finish up something else first 👍

[9001]

alright, should be good now -- there's a new build here if you'd like to give it a go: https://ocv.me/copyparty/beta/copyparty-sfx.py

but! I should mention that you're bumping into a design limitation with a config like that --

every time copyparty is restarted, none of the volumes will be accessible to anybody until each volume's owner sends their first request to the server, since they're all forgotten on shutdown -- unless the volumes are inside a parent volume which does allow the intended access, in which case all the user volumes will inherit that permission until the user shows up again... yep, I know...

unfortunately, this limitation is not likely to go away anytime soon, since trying to think of a safe and reliable way to remember+restore the volumes just gives me a headache every time heh

so, one workaround for your particular config could be to make the toplevel volume something like:

[/]
  ./
  accs:
    g: *

if you're planning to continue playing with this over the weekend then I'll wait until sunday to post the new release, since there might be more edge-cases to weed out still -- otherwise I'll do it tomorrow eve 👍

also, just curious since you're using the sfx -- how are you running the idp service? does debian package something that's convenient enough to use without docker, or is that running on a remote box / in docker? just fishing for more ideas / suggestions to add to the docs :>

[Sirmentio]

I'm running just it on the base system with the systemd service. I have trouble using docker a lot of the time, mostly with getting HTTPS to work.

Either way, thank you! This works perfectly.