Restore from backup. No point in trying to figure out what changed, how and where.
that sounds to ge good advice, but I'm pretty sure they would yave done that themselves, if they had a backup.
and, if you read the whole post, you'll know that they are physically unable to keep a backup.
I want everything to be owned by myuser, group media
Wait, "everything?" Yeah, that's probably contraindicated. You don't want to be changing ownership of stuff in, say, /etc or /bin or whatever to your user. For the most part, stuff in those locations should be owned by root:root. If there are exceptions (things that should be owned by root:), the package manager will make sure they're set as they should be.
No no, sorry. Just on the specific filesystem which only contains media files.
As root:
cd /filesystem/in/question
chown myuser:media -R /filesystem/in/question
find -exec chacl -B -- {} +
find -exec chmod 644 -- {} +
find -type d -exec chmod 755 -- {} +
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?
chacl is from IRIX, and is included for backward compatibility afaik. setfacl is the more common command.
setfacl -b is the same as chacl -B IIRC
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?
almost. it runs the command in batches, if you have few enough files it may only run it once. this shouldn't make it slower, but actually faster.
and yes, linux does not use ACLs by default. ~~on ext4 usage of ACLs is not even enabled by default, but only if you set it up with the right mount option~~
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.
aclis 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.
oh, that's right, sorry. it must have changed in recent years.
so I haven't either found a definitive answer to whether it is a default mount option, but the closest I found is almost it: man mount says to look in man ext4, and there itsays the defaults are determined by the filesystem superblock.
the superblock's settings can be viewed with tune2fs -l /dev/your_blockdev, and according to the "default mount options" line I indeed have acl enabled by default on all my ext4 filesystems.
so in the end, the default is determined by the tool that makes the filesystem. mkfs.ext4 reads them from /etc/mke2fs.conf if not overridden with an argument. on my system tue acl option is right there in this file.
and that also means that this depends not on your current system, but on the system where the filesystem was created.
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?
Indeed. If possible, it is typically what you want (as opposed to find ... -exec ... {} \; which runs command for each found file) since it will run faster. You want find ... -exec ... {} \; if the command you’re executing can run on single file only or you’re dealing with legacy system without -exec ... {} + support.
Is there a reason to run
find -exec chmod 644 -- {} +
rather than
find -type f -exec chmod 644 -- {} +
?
find -type f -exec chmod 644 -- {} +
find -type d -exec chmod 755 -- {} +
will only affect regular files and directories. There are other type
of files (specifically block and character devices, named pipes and
sockets) which those two commands would leave unaffected. In
practice, I suspect you don’t have any of those to worry about so you
can use -find f.
To back them up, perhaps cp -r --preserve=xattrs --attributes-only (or --preserve=all if you don't want only xattrs)
Wouldn't that back up the media files themselves also, not just the attributes?
Not with --attributes-only.
One way could be to grep your history, then compare the matches against a distro source?
It'll be tedious if it's lots, but might be a solution if you don't have a backup.
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.
What have you been trying to do exactly? I've got into plenty of permissions messes in the past, and my gut feeling is that you might be overcomplicating things here
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.
Don't do that. I've done worse, but that's no excuse. You need to use the setgid bit (chmod g+s) of the parent folder and then look into the umask config option for whichever of your applications are creating files/directories... and what umask even is ofc lol
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.
It's not that difficult, and you don't need to become an expert — just find out what you need to achieve what you'd trying to do rn. Tbh I still use online calculators for permissions a lot of the time. Maybe see what you can find in the servarr wiki on the subject?
I mean, too late for you now. But I have a script that backs up just the permissions and owners for a given folder hierarchy.
I use it because I backup to a cloud backup platform that doesn't save them. So these files are backed up with the data so the files and permissions/owners can be restored in an emergency.
But you could of course also use the file to restore permissions after a user generated mistake too.
can you share the script?
Yeah. Only on my phone right now but will get it and post here later/tomorrow.
OK so it's fairly simple. You need to install the acl package (or whatever equivalent package contains getfacl/setfacl. Then you can use that to dump the data from an entire structure into a file (I also then bzip that). Then I backup all installed packages to help with a restore too.
So the script looks like:
#!/bin/bash
cd /etc
/usr/bin/getfacl -R . | /usr/bin/bzip2 -9 >PERMISSION_BACKUP.bz2
chmod 600 PERMISSION_BACKUP.bz2
cd /home
/usr/bin/getfacl -R . | /usr/bin/bzip2 -9 >PERMISSION_BACKUP.bz2
chmod 600 PERMISSION_BACKUP.bz2
cd /root
/usr/bin/getfacl -R . | /usr/bin/bzip2 -9 >PERMISSION_BACKUP.bz2
chmod 600 PERMISSION_BACKUP.bz2
cd /var
/usr/bin/getfacl -R . | /usr/bin/bzip2 -9 >PERMISSION_BACKUP.bz2
chmod 600 PERMISSION_BACKUP.bz2
/usr/bin/apt list --installed | /usr/bin/bzip2 -9 >/root/INSTALLED-PACKAGES.bz2
chmod 600 /root/INSTALLED-PACKAGES.bz2
To restore you change to the folder the backup was taken from, unbzip the file (or uncompress live via pipe) and use setfacl --restore=
thanks for getting back to me. :)
I am curious what kind of situation would screw up your /etc/ directory?
It's for backup purposes mainly. A lot of cloud backup providers don't store permissions.
So if I restore the data I can then restore the permissions after. So these are the folders I am backing up (with some exceptions in /var)
Ah I see. Thanks! The data and the attributes are stored separately.
Well sudo find ${path} -type d exec chmod 750 {}; to fix the folders first Then sudo find ${path} -type f exec chmod 640 {}; to fix the files
After that sudo chown -Rv my user:media ${path} and everything should be sorted
If you use u+rwX style syntax instead of 755, the capital x will only apply to folders. Then you can do it all in one command and don't need find.
X applies to directories and executable files. Presumably, OP wants
to clear the executable bits from any files and +X won’t do that.
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.
But I need x on directory, because that’s required to enter/read the directory. If I understand properly.
That’s why bacon listed find ${path} -type d exec chmod 750 {}; as first command. See also my reply.
You need x on directories and executable files.
Honestly tho you could leave x on absolutely everything and probably be fine. Just pull it off your media / untrusted downloads.
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.
Not every version of chmod supports that and you really don’t want your media files to be executable
Why not?
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.
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?
There are no "defaults". If it's just media, and you don't care who can read it: chmod -R 755 /your/directory
That sets your user to full access, and all other users to read and execute whatever files are in there. That's as close to a default as you can get. Switch it to 744 for strict read-only for other users aside from yourself.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0