Accidentally changed permissions on entire /etc directory…or did I?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I've been setting up a hosting platform on a VPS running Centos 7. I've been going through some admin tasks and accidentally ran a couple commands within the /etc directory:
find . -type d -exec chmod 755 ;
find . -type f -exec chmod 644 ;
I know how potentially grave a mistake this is but upon using ls -lR within /etc I found that these changes had been far from universally implemented. There is still a ton of nuance in the permissions of the files and directories within /etc.
I know it would be diligent to nevertheless reinstall Centos on this VPS, but before I do, can anyone explain why the ls -lR command is showing me tons of variation in the permissions of /etc? Is it possible the commands were malformed or didn't actually execute?
I've also reviewed other similar questions and solutions such as rpm --setperms don't seem helpful here since that would only reset the permissions on rpm-installed packages. Any advice is greatly appreciated.
If you'd like to see any output, logs, or need more info I'll update the question with it.
linux permissions find chmod
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
asked Mar 23 at 23:14
baelx
1064
add a comment |Â
up vote
0
down vote
favorite
I've been setting up a hosting platform on a VPS running Centos 7. I've been going through some admin tasks and accidentally ran a couple commands within the /etc directory:
find . -type d -exec chmod 755 ;
find . -type f -exec chmod 644 ;
I know how potentially grave a mistake this is but upon using ls -lR within /etc I found that these changes had been far from universally implemented. There is still a ton of nuance in the permissions of the files and directories within /etc.
I know it would be diligent to nevertheless reinstall Centos on this VPS, but before I do, can anyone explain why the ls -lR command is showing me tons of variation in the permissions of /etc? Is it possible the commands were malformed or didn't actually execute?
I've also reviewed other similar questions and solutions such as rpm --setperms don't seem helpful here since that would only reset the permissions on rpm-installed packages. Any advice is greatly appreciated.
If you'd like to see any output, logs, or need more info I'll update the question with it.
linux permissions find chmod
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
asked Mar 23 at 23:14
baelx
1064
Well IIRCfinddoesn't follow symlinks by default - maybe that's what you're observing?
– steeldriver
Mar 24 at 1:36
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I've been setting up a hosting platform on a VPS running Centos 7. I've been going through some admin tasks and accidentally ran a couple commands within the /etc directory:
find . -type d -exec chmod 755 ;
find . -type f -exec chmod 644 ;
I know how potentially grave a mistake this is but upon using ls -lR within /etc I found that these changes had been far from universally implemented. There is still a ton of nuance in the permissions of the files and directories within /etc.
I know it would be diligent to nevertheless reinstall Centos on this VPS, but before I do, can anyone explain why the ls -lR command is showing me tons of variation in the permissions of /etc? Is it possible the commands were malformed or didn't actually execute?
I've also reviewed other similar questions and solutions such as rpm --setperms don't seem helpful here since that would only reset the permissions on rpm-installed packages. Any advice is greatly appreciated.
If you'd like to see any output, logs, or need more info I'll update the question with it.
linux permissions find chmod
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
asked Mar 23 at 23:14
baelx
1064
I've been setting up a hosting platform on a VPS running Centos 7. I've been going through some admin tasks and accidentally ran a couple commands within the /etc directory:
find . -type d -exec chmod 755 ;
find . -type f -exec chmod 644 ;
I know how potentially grave a mistake this is but upon using ls -lR within /etc I found that these changes had been far from universally implemented. There is still a ton of nuance in the permissions of the files and directories within /etc.
I know it would be diligent to nevertheless reinstall Centos on this VPS, but before I do, can anyone explain why the ls -lR command is showing me tons of variation in the permissions of /etc? Is it possible the commands were malformed or didn't actually execute?
I've also reviewed other similar questions and solutions such as rpm --setperms don't seem helpful here since that would only reset the permissions on rpm-installed packages. Any advice is greatly appreciated.
If you'd like to see any output, logs, or need more info I'll update the question with it.
linux permissions find chmod
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
asked Mar 23 at 23:14
baelx
1064
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
edited Apr 8 at 15:21
Jeff Schaller
31.2k846105
31.2k846105
asked Mar 23 at 23:14
baelx
1064
asked Mar 23 at 23:14
baelx
1064
asked Mar 23 at 23:14
baelx
1064
1064
Well IIRCfinddoesn't follow symlinks by default - maybe that's what you're observing?
– steeldriver
Mar 24 at 1:36
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35
add a comment |Â
Well IIRCfinddoesn't follow symlinks by default - maybe that's what you're observing?
– steeldriver
Mar 24 at 1:36
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35
Well IIRC
find doesn't follow symlinks by default - maybe that's what you're observing?– steeldriver
Mar 24 at 1:36
Well IIRC
find doesn't follow symlinks by default - maybe that's what you're observing?– steeldriver
Mar 24 at 1:36
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
I'm afraid there was no magic bullet here - given that I couldn't know the extent of the damage, I was forced to reinstall my system. Thanks to those who commented.
answered Jun 20 at 3:41
baelx
1064
It's a shame we never got to know whether you executed thefindcommands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of/etcalong with other essential system files.
– Kusalananda
Jun 20 at 5:46
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
I'm afraid there was no magic bullet here - given that I couldn't know the extent of the damage, I was forced to reinstall my system. Thanks to those who commented.
answered Jun 20 at 3:41
baelx
1064
It's a shame we never got to know whether you executed thefindcommands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of/etcalong with other essential system files.
– Kusalananda
Jun 20 at 5:46
add a comment |Â
up vote
0
down vote
accepted
I'm afraid there was no magic bullet here - given that I couldn't know the extent of the damage, I was forced to reinstall my system. Thanks to those who commented.
answered Jun 20 at 3:41
baelx
1064
It's a shame we never got to know whether you executed thefindcommands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of/etcalong with other essential system files.
– Kusalananda
Jun 20 at 5:46
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
I'm afraid there was no magic bullet here - given that I couldn't know the extent of the damage, I was forced to reinstall my system. Thanks to those who commented.
answered Jun 20 at 3:41
baelx
1064
I'm afraid there was no magic bullet here - given that I couldn't know the extent of the damage, I was forced to reinstall my system. Thanks to those who commented.
answered Jun 20 at 3:41
baelx
1064
answered Jun 20 at 3:41
baelx
1064
answered Jun 20 at 3:41
baelx
1064
answered Jun 20 at 3:41
baelx
1064
1064
It's a shame we never got to know whether you executed thefindcommands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of/etcalong with other essential system files.
– Kusalananda
Jun 20 at 5:46
add a comment |Â
It's a shame we never got to know whether you executed thefindcommands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of/etcalong with other essential system files.
– Kusalananda
Jun 20 at 5:46
It's a shame we never got to know whether you executed the
find commands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of /etc along with other essential system files.– Kusalananda
Jun 20 at 5:46
It's a shame we never got to know whether you executed the
find commands as root or not. If you did not, then no harm would have been done. Also, any backup solution should have included a backup of /etc along with other essential system files.– Kusalananda
Jun 20 at 5:46
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f433173%2faccidentally-changed-permissions-on-entire-etc-directory-or-did-i%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Well IIRC
finddoesn't follow symlinks by default - maybe that's what you're observing?– steeldriver
Mar 24 at 1:36
I wasn't aware of that so yes I would suppose that explains it... I had hoped there was some magic that could save me here but I've accepted my fate now
– baelx
Mar 25 at 19:26
Did you run these commands as root?
– Kusalananda
Apr 8 at 15:35