10
Question on chown in parallel
(sh.itjust.works)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 May 2024
10 points (100.0% liked)
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
Thanks for adding that tidbit at the end. The reason that permissions get out alignment is due to different non-privledged accounts (for saftey) will write or copy files somewhat regularly from outside of the main system. I am the furthest thing from a linux expert so maybe you would have a recommendation or better insight after explaining that? This necessitates changing the owner and permissions regularly, especially when I need to interact with the files adhoc and have to wait for my script to run and complete.
If you have multiple users writing to a directory, you should be relying on groups, permissions, and sgid and not care who the owner is.
But what if user A in a new group creates dir "abc" - will dir "abc" automatically be set to the correct group? I would think the group permission would be just like the user permission, not set until manually set.
Yeah since I learned on Windows servers for 20 years, I'm struggling on permissions and groups in Linux in general.
In Windows it's as easy as enabling 'children inherit parent' and then the users can go and create whatever and if they can write, they'll write it with inherited from the parent permissions. If you change a folder deeper, you can unlink inheritance from the parent and then it could also optionally be the new parent for all children permissions.
I tried a couple of times to do this in Linux and I've always struggled due to my own lack of knowledge and understanding. I feel reading it I keep coming to the wrong conclusion too perhaps based on my experience and bias in reading it.
Anyway I know it's not helpful but I feel the struggle.
Thanks for chiming in, im glad its not just me. I feel like i have a much stronger understanding on things more complicated tham groups! That makes it feel worse
I don't really understand your use case.
It sounds like you have multiple users creating files in a directory, and some users are creating them with more-restrictive permissions than you want -- like, you want to force them to make their stuff accessible by everyone else -- and you're trying to avoid that by regularly modifying all the permissions?
If you set the sgid bit on the parent directory, then by default, things created in that directory will inherit the group of the parent directory.
But a user can still change permissions so that that isn't the case.
It's possible that you could use ACLs or something like that to address your problem, but I don't know what it is that you're trying to achieve.
What you proposed with sgid sounds like it might be what i need. All of the users are controlled my me, it's just when they connect to the smb share of the main system from other devices, i figured it was good security to use an account that is separate from my main account on the system, so they can't access the entire system or execute sudo commands
If this is specific to a Samba server, it looks like you can set it to use whatever uid/gid you want.
https://unix.stackexchange.com/questions/530038/remap-uid-in-samba-share
Hrm, you might look into file ACLS.
https://serverfault.com/questions/444867/linux-setfacl-set-all-current-future-files-directories-in-parent-directory-to
serfaclsis 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. :)
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
fdcan turn a script into a very short one-liner; and unlikefind, it runs execs in parallel by default: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.
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.