/etc folder permissions?


14 posts in this topic Last Reply

Recommended Posts

I just finished setting up ssh keys on unraid but when I attempted to log back in, I receive an error saying the authorized keys were ignored due to bad permissions on /etc.

 

I do see /etc is owned by the admin:1000 account I have set up while the rest of the root folders are owned by root:root. Within /etc, the only directory owned by admin:1000 is rc.d.

 

Should I chown root:root /etc or will that cause problems? I have no idea why /etc is owned by admin:1000

 

Thanks

Link to post

/etc like all other OS folders are in RAM and won't survive reboot. If you need to make changes to these you will need a script that runs on boot to reapply changes. User Scripts plugin can help with getting your script run at boot.

Link to post
1 hour ago, elkaboing said:

I do have an "admin" account

Is that an account that you created in the Unraid webUI? Those accounts are strictly for network access of files, and /etc isn't accessible on the network unless you have hacked SMB or something.

 

Or did you somehow create that account at the Linux level of things? Unraid isn't intended to be a general purpose multiuser Linux OS. Only root should have access to the command line or webUI. If you want a general purpose multiuser Linux, create a VM.

 

I don't know how you managed to get that owner on /etc but you should not do that.

Link to post

I agree - no idea how the ownership of /etc was changed.

 

I created the admin account when I was first setting-up Unraid awhile ago but never used it - ended up using a different account.

 

I just deleted the admin account and chown'd /etc root:root - I'll be curious to see if anything changes after a reboot.

 

Thanks for the troubleshooting help

Link to post
On 1/5/2021 at 5:14 AM, elkaboing said:

I do see /etc is owned by the admin:1000 account I have set up while the rest of the root folders are owned by root:root. Within /etc, the only directory owned by admin:1000 is rc.d.

In my experience, this means you probably have a plugin that installed files owned by the user id 1000 (this is assigned to the first user created in any Unraid/Linux system) and group id 1000

So when you have a chance to reboot, try so to make sure its not an accidental chown.

And if it did comeback, you'll have to inspect each of your plugins to determine if any is incorrectly built.

Link to post
1 hour ago, ken-ji said:

In my experience, this means you probably have a plugin that installed files owned by the user id 1000 (this is assigned to the first user created in any Unraid/Linux system) and group id 1000

So when you have a chance to reboot, try so to make sure its not an accidental chown.

And if it did comeback, you'll have to inspect each of your plugins to determine if any is incorrectly built.

Based on your info, I dug into /etc/rc.d and see that rc.ipmicfg, rc.ipmiseld and rc.ipmitail have group 1000 permissions. So it was IPMI support plugin that changed the permissions. I’ll crown it back to root and see what happens.

Link to post

so I took a look at the ipmi plugin and plugin package it installs is badly built.

image.png.be380c9d2e866c9d2f2bbd5f7b38e20f.png

Granted when the package is installed and doesn't have a derekmacias user or group, they will fallback to the numeric value which happens to be 1000 hence admin:1000 for @elkaboing.

This will break SSH access and maybe a few other such things. The plugin author @dmacias probably doesn't use ssh (and neither do the other IPMI users, hence they haven't seen this issue)

Link to post
so I took a look at the ipmi plugin and plugin package it installs is badly built.
image.png.be380c9d2e866c9d2f2bbd5f7b38e20f.png
Granted when the package is installed and doesn't have a derekmacias user or group, they will fallback to the numeric value which happens to be 1000 hence admin:1000 for @elkaboing.
This will break SSH access and maybe a few other such things. The plugin author @dmacias probably doesn't use ssh (and neither do the other IPMI users, hence they haven't seen this issue)
Thanks for the heads up. I do use ssh but authorized keys only. I also see the 1000 user and group on etc and rc.d but everything else in etc is root. I compile my packages on my laptop in Linux. I usually use root to compile them but obviously didn't on the last update. I'll push an update when I get home.
Link to post

Took care of it, permissions are back to root:root. Thanks @dmacias! Interesting you were still able to use your ssh keys, that’s what identified the issue for me. I was receiving an error saying my keys were ignored due to bad permissions on /etc.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.