

thanks for getting back to me. :)
I am curious what kind of situation would screw up your /etc/ directory?
thanks for getting back to me. :)
I am curious what kind of situation would screw up your /etc/ directory?
Is there a reason to run
find -exec chmod 644 -- {} +
rather than
find -type f -exec chmod 644 -- {} +
?
An mp3 or a pdf has no business doing anything. The whole point of file permissions is to prevent the user from accidentally doing stuff they don’t mean to do.
If you downloaded a malicious file that had some code in it, you could accidentally execute the code. Or maybe some legitimate code that means one thing in the file format but a different thing when executed accidentally.
Even excluding the possibility of malice, I think it would screw up things like tab completion to have every file be an executable. Or if I double click in the GUI file manager, will it try (and fail) to run the .avi as an application instead of opening in VLC?
I’m sure you could get a more comprehensive answer if you post a new thread or search on the web.
I did try to setgid thing but maybe it made things worse and not better.
what umask even is ofc lol
my conclusion also… I did kind of get to the understanding that the correct way to do this is with umask but everytime I think “I’m just going to sit down and learn about umask” I immediately am forced to admit defeat and give up. Which is why I didn’t make a post about solving the original problem, rather just to try to dig out my current hole first.
on ext4 usage of ACLs is not even enabled by default
Is that the case? One reason I included the information is because I found conflicting info and I am unsure. I specifically recall reading it is default on ext4 but not ext3.
acl
is specified as a default mount option when creating an ext2/3/4 filesystem
This SE thread has a coment dated 2015:
Recent distro have ACL mount option included by default (since kernel 2.6). So it’s not mandatory to redefine it in /etc/fstab (or similar). Non exhaustive list of filesystems concerned: ext3, ext4, tmpfs, xfs and zfs .
I don’t think I have read anywhere it is not default for ext4, only for earlier exts.
Right because there are no legitimate executable files in this set. So it is OK to blanket remove x from any files tat have acquired it.
But I need x on directory, because that’s required to enter/read the directory. If I understand properly.
I’m not familiar with chacl
(“change the access control list of a file or directory”). Is is similar to setfacl
(“set file access control lists”)? A matter of preference/habit?
It seems like -B
does “Remove all ACLs”. Which I guess is what I am asking for? Files on linux are OK to have no ACLs?
About the find ... {} +
, I see {} +
runs the specified command on the selected files, but the command line is built by appending each selected file name at the end; the total number of invocations of the command will be much less than the number of matched files.
So does it wait until it has found all the matches to run the command as a giant batch instead of running it as it finds matches?
No no, sorry. Just on the specific filesystem which only contains media files.
I think the main issue was that various applications that are involved have their own user account, but you put all those users in the media
group so they are all supposed to be able to access each others files. But when they would create a new file, it never gets chowned to :media
, it is only owned by the group of the creating system user. I was trying to manage it so that all files owned by user jellyfin
would also be modifiable by myuser
.
I wanted this to be managed correctly by the file system or something but maybe once I can get a fresh slate, just make a script that constantly runs to chown -R :media
might be more straightforward.
It’s hard to sort out what happened because some tasks completed, others didn’t. Some commands were following symlinks, others weren’t. Some files already had permissions that prevented the current user from modifying them so were untouched. And some files have been moved. There is no way to sort it out from the history.
When I was getting myself into this mess, I found different opinions about whether it’s faster to find, them modify attributes for only those files which require it, OR if you should just modify the attributes of all files en masse.
I tried both ways and they both took a very long time; didn’t do any objective comparison.
my version does support it, it’s fine
if it wasn’t supported shouldn’t it throw an error or do nothing? or in other versions is X
a synonym to x
?
Wouldn’t that back up the media files themselves also, not just the attributes?
can you share the script?
Ah I see. Thanks! The data and the attributes are stored separately.