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

/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.

Thanks for the quick response. Should /etc be owned by root:root? I didn't do anything, knowingly, to change it to admin:1000.

2 minutes ago, elkaboing said:

Should /etc be owned by root:root?

Is for me and I'm pretty sure it should be. Do you have a user named admin?

I do have an "admin" account

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.

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

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.

Great info, thank you

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.

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

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)

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

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.

Just saw updates of two packages (IPMI & Nerd Tools) from @dmacias.

@elkaboing, you should check if that is better.  

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.