Skip to content

mod: first check then chown - #402

Open
schenklklopfer wants to merge 2 commits into
lbr38:develfrom
schenklklopfer:devel
Open

mod: first check then chown#402
schenklklopfer wants to merge 2 commits into
lbr38:develfrom
schenklklopfer:devel

Conversation

@schenklklopfer

Copy link
Copy Markdown
Contributor

As we restart our repomanager a lot, we noticed there is a chown running minutes.
Whilst this everything is very slow.

Checking is way faster than setting.

So first check, if it fails set the ownership new.

Checking is way faster than setting.

First check, if it fails set the ownership new.
@lbr38

lbr38 commented Jul 28, 2026

Copy link
Copy Markdown
Owner

Your proposal is not optimal, since a recursive chown is still applied if even a single file has the wrong permissions. What about:

find "$DIR" \( ! -uid "$UID" -o ! -gid "$GID" \) -exec chown "${UID}:${GID}" {} +

This will only modify files with incorrect permissions and avoid a recursive chown.

@schenklklopfer

Copy link
Copy Markdown
Contributor Author

Yes, that's a way better thing for a few wrong files.
But it will take forever if all files needs to be fixed.

At the first instance I do not understand why this is needed at all.
Maybe there are cases, where all files needs fixing?
But only a few ones?

I do not know which case that could be...

Basically I just want to avoid the permanent chown on our half TB of files via slow NFSv3... This takes about 15 minutes.
And slows down the whole system after a restart of the container.

@lbr38

lbr38 commented Jul 28, 2026

Copy link
Copy Markdown
Owner

But it will take forever if all files needs to be fixed.

If all files need to be fixed, so they have to be fixed no matter how much time it takes.. otherwise the app will not work. But that's in the worst-case scenario. In fact, permissions on files should never change. This chown is there as a safeguard, in case someone changes the file permissions by mistake. In this case, a restart of the container will fix the permissions automatically.

I understand this could be a performance issue.

Did you tried to launch the command I gave you in the previous message on your instance to see what time it takes to execute?

@schenklklopfer

Copy link
Copy Markdown
Contributor Author

Not yet.
At the moment we test other performance improvements.

But next week I can test your command on our production.

@lbr38
lbr38 force-pushed the devel branch 3 times, most recently from 00ffb48 to e086253 Compare August 4, 2026 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants