linux4noobs

1356 readers

1 users here now

linux4noobs

Noob Friendly, Expert Enabling

Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.

Seeking Support?

Mention your Linux distro and relevant system details.
Describe what you've tried so far.
Share your solution even if you found it yourself.
Do not delete your post. This allows other people to see possible solutions if they have a similar problem.
Properly format any scripts, code, logs, or error messages.
Be mindful to omit any sensitive information such as usernames, passwords, IP addresses, etc.

Community Rules

Keep discussions respectful and amiable. This community is a space where individuals may freely inquire, exchange thoughts, express viewpoints, and extend help without encountering belittlement. We were all a noob at one point. Differing opinions and ideas is a normal part of discourse, but it must remain civil. Offenders will be warned and/or removed.
Posts must be Linux oriented
Spam or affiliate links will not be tolerated.

founded 1 year ago

MODERATORS

PlutoParty@programming.dev

Question on chown in parallel (sh.itjust.works)

submitted 6 months ago by Ponziani@sh.itjust.works to c/linux4noobs@programming.dev

15 comments fedilink hide all child comments

Hello I am seeking a simple solution to running a list of "chown -R" " commands in script.sh

It takes a long time to sequentially execute all of these chown commands recursively because the directories have so many files. I want to be able to tackle the root level directories in parallel to speed things up. I imagine there must be a simple way to do this while keeping the list of commands in a single file. xargs and some of the other things I saw online looked like bad fits or would be over engineering this problem.

you are viewing a single comment's thread
view the rest of the comments

[–] ricecake@sh.itjust.works 3 points 6 months ago (1 children)

Hrm, you might look into file ACLS.

https://serverfault.com/questions/444867/linux-setfacl-set-all-current-future-files-directories-in-parent-directory-to

serfacls is a command that lets you make user (or other) level permissions changes outside of the usual ownership semantics.
So you could for example do something like setfacl -d -R u:<your username>:rwx /the/very/top/directory/ That should make it so that newly created files and folders have a default acl allowing you access. Run it again with the m flag to modify existing files.
It'll take a minute to loop through everything, but you should only have to run it once so it's not a recurring issue.

I hope that gets you what you need. :)

[–] sxan@midwest.social 1 points 6 months ago (1 children)

facls are the shizzle. Seriously. I'm really not sure why people use chmod at all anymore. It's fewer characters, maybe?

For OP, a tool like fd can turn a script into a very short one-liner; and unlike find, it runs execs in parallel by default:

sudo -E me=$(id -un) fd . \<path> -t f -x setfacl -m u:${me}:rw '{}'
sudo -E me=$(id -un) fd . \<path> -t d -x setfacl -m u:${me}:rwx '{}'

will do the thing in parallel; the first line, for all the files; the second, for all the directories.

As others have said, if you're needing to do this a lot, it's best to fix whatever is setting the perms in the first place, or as @ricecake and others have said, set the perms/facls to be sticky so they get inherited.

facls are far more expressive than base perms, and are supported by every major, current, Linux filesystem. Not FAT, but ACLs on FAT FSes are all f'ed up anyway.

[–] ricecake@sh.itjust.works 2 points 6 months ago

My guess is that it's not "the standard" for managing file ownership stuff, since it doesn't manage ownership. As a result, they're shown less often in tutorials and tool output.
The ownership semantics still needs to exist and get managed, and so a lot of less sophisticated software will just check ownership, not it's actual ability to access.

Tools and capabilities come quick, but the ecosystem as a whole moves glacially slow. Often that's good, because it means user land APIs and programs don't often just fail for no good reason, which creates the stability that makes it popular and useful. It also makes it painful to get "new stuff" into widespread use, where "new" means less than 30 years old.
You see the same thing with selinux. It's fine now! But it's still scary. And we'll finally have btrfs as the standard in 2040 I'll wager.