Issues with SSH - Root directory ownership


Recommended Posts

Hi there all, I've recently updated to 6.9.0-rc2, however this was occurring before on the last beta, so I'm pretty sure it's not related to an UnRaid version itself.

 

Something keeps changing the ownership of my root directory (/, not /root) to nobody:users from the normal root:root. This seems to upset SSH's strict owernship checks, preventing me from using a public key to log in.

image.png.182e054be72d91c57c391820772f3919.png

 

Does anyone know what might be causing this?

 

  • I've seen the ownership change to both this and my "wolf" user.
  • No Docker containers have the root directory mounted
  • Ownership is correct at first boot, and for a random amount of time afterwards
  • using "chown root:root /" does not fix the problem, SSH still complains - A chmod needed?

 

The SSH error: "Authentication refused: bad ownership or modes for directory /"

 

Any help would be much appreciated.

Link to comment
5 hours ago, Alexstrasza said:

Conclusion of the problem: It was caused by a faulty update of the Parity Check Tuning plugin. Removing the plugin and rebooting resolves the issue.

You shouldn't even need to remove the plugin. At least for me, the proper ownership of the / directory was restored by simply rebooting UnRAID.

Edited by weirdcrap
Link to comment
17 hours ago, Alexstrasza said:

Conclusion of the problem: It was caused by a faulty update of the Parity Check Tuning plugin. Removing the plugin and rebooting resolves the issue.

 

 

I took me a while, but I got to the root cause I think.  I was surprised it had suddenly happened when I had not changed anything in the package creation area (for which I run a script).  I found it depended on which of my various unRaid environments I used to run the package creation :(  It still surprises me that the effect was to change the ownership of existing folder rather just the new ones being added.  The reason the problem arose in the first place might be of interest to other developers in case they encounter a similar scenario.

  • I have a Dropbox container using a Dropbox share on my main unRraid server which holds the source of the plugin. 
  • I use my Windows machine (which is also running Dropbox) as the main editing environment as I have better tools there.
  • I use Dropbox to synchronise the source between all my unRaid environments so any change made in Windows appears in my unRaid environments within a few seconds.
  • I was mounting this share on the other environments using a Unassigned Devices SMB share
  • My script that builds the package specifies that the ownership of the files should be root:root and if the package is built on the main server this is how the ownership ends up.
  • On the environments using the SMB share the ownership was showing as nobody:users and the command to change it to root:root was being silently ignored. 

By changing the Dropbox share to be a NFS share the build script CAN change the ownership to the expected values.

 

  • Like 2
Link to comment
5 hours ago, itimpi said:

 

 

I took me a while, but I got to the root cause I think.  I was surprised it had suddenly happened when I had not changed anything in the package creation area (for which I run a script).  I found it depended on which of my various unRaid environments I used to run the package creation :(  It still surprises me that the effect was to change the ownership of existing folder rather just the new ones being added.  The reason the problem arose in the first place might be of interest to other developers in case they encounter a similar scenario.

  • I have a Dropbox container using a Dropbox share on my main unRraid server which holds the source of the plugin. 
  • I use my Windows machine (which is also running Dropbox) as the main editing environment as I have better tools there.
  • I use Dropbox to synchronise the source between all my unRaid environments so any change made in Windows appears in my unRaid environments within a few seconds.
  • I was mounting this share on the other environments using a Unassigned Devices SMB share
  • My script that builds the package specifies that the ownership of the files should be root:root and if the package is built on the main server this is how the ownership ends up.
  • On the environments using the SMB share the ownership was showing as nobody:users and the command to change it to root:root was being silently ignored. 

By changing the Dropbox share to be a NFS share the build script CAN change the ownership to the expected values.

 

 

Thanks for the breakdown, and don't worry about the breakage - I was worried it was *me* doing something dumb 😅!

 

5 hours ago, weirdcrap said:

Interesting, you may have more than one plugin to blame here then. As Ken-ji mentioned in that other thread, you will probably need to go through the plugins one by one to figure out which one is changing your ownership and ask the author to fix it.

 

Strangely the issue hasn't re-occurred since. If I notice the same symptoms though, at least I know what the cause is this time 🙂

 

Link to comment

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.