February 12, 20215 yr 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. 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.
February 12, 20215 yr Author Ah, I've just seen this thread which somehow I overlooked earlier being used by others with this problem. It might be related to a plugin update: Edited February 12, 20215 yr by Alexstrasza
February 12, 20215 yr Author 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.
February 12, 20215 yr 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 February 12, 20215 yr by weirdcrap
February 12, 20215 yr Author 34 minutes ago, weirdcrap said: 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. When I rebooted the issue re-occurred a while later.
February 13, 20215 yr 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. Edited February 13, 20215 yr by weirdcrap
February 13, 20215 yr Community Expert 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.
February 13, 20215 yr Author 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 🙂
Archived
This topic is now archived and is closed to further replies.