joshstrange

So I just found this thread and removing/commenting out `PermitRootLogin yes` does prevent password login. SSH will still prompt for the password (odd, I've never seen this before when I've setup a server to be key-only) but it will not accept the correct root password. I guess this is better than nothing but it's frustrating that I had this working perfectly before upgrading and now sshd doesn't appear to respect the config I give it (notably `PubkeyAuthentication yes` and `PasswordAuthentication no`).

Sorry I missed this reply, unfortunately it doesn't solve my problem. It may make it so I can login with my keys (I already have that working) but it does nothing to prevent passwords when logging in. As in I can still `ssh root@MYIP` and get a password prompt that takes my password and logs me in. I want to completely prevent that. Make SSH key-ONLY. It's very odd to me that I've edited the `/etc/ssh/sshd_config` file and told it to not allow PasswordAuthentication and yet SSH still works without a key.

I know I had this working on <6.9 but I built a new UnRaid box recently, installed 6.10, and I think it broke. In my /boot/config/go file I have: mkdir -p /root/.ssh cp /boot/custom/ssh/* /root/.ssh chmod 700 /root/.ssh chmod 600 /root/.ssh/* echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config echo "PasswordAuthentication no" >> /etc/ssh/sshd_config /etc/rc.d/rc.sshd restart Which should take my authorized keys file in /boot/custom/ssh/, move it to the right place, set the correct permissions, disable password login, and restart the ssh daemon. It does correctly allow me to login with a key but I can also still login with my password which I do not want. In past versions of UnRaid I know this configuration worked so I'm confused as to what I'm doing wrong this time around. I also tried uncommenting the: PermitRootLogin prohibit-password Line and restarting ssh but it didn't help. Any assistance would be greatly appreciated. Thank you!

Sorry, I should have added a diagnostic from the start. I only have one from 6.6.7, I stupidly forgot to do one on 6.9.2 before I downgraded. If needed I can attempt another upgrade since I now have a clean up/downgrade path tower-diagnostics-20211028-1027.zip

After one my SATA cables died to one of my cache drives (something that UnRaid did not alert me to or alter the UI, it showed a gray ball next to the drive and reported no errors despite /var/log/syslog screaming about superblock issues) I decided to upgrade UnRaid finally. I upgraded to the newest version and while I could connect to it from my local network I was unable to access the internet from the UnRaid box (it could still see/ping everything on the local network). My DNS servers were set to 8.8.8.8/8.8.4.4. It appears that in the upgrade my default route was set to go through br1 (on 6.6.7 it is showing br0) and I think that was my issue but I wasn't clear on how to change that safely and how to revert back to br1 if my guess that it should be br0 was wrong. After a failed attempt to update the DNS and having to pull the USB drive off the motherboard to manually edit the network config I wasn't in a mood to attempt any new network-related fixes so I downgraded. Apart from the panic when it didn't show my cache drives and pretended like they were new drives I was able to get back up and running on 6.6.7. My questions is: Why did UnRaid change my default route to br1 in the upgrade and if this is the root of my problem, like I think it is, how do I safely switch from br1 to br0? I have included a screenshot of 6.6.7 (working) config. I sadly didn't screenshot the 6.9.2 config but I can confirm it said it was going through br1 for the default traffic and on the command line when I listed the routes (`ip route` is what I think I ran) it showed the br1 as "linkdown".

I tried different browsers and different devices but the GUI stayed in that odd state. Once I was sure the rebuild was complete (mind you the array was accessible this whole time, it just didn't look like it was via the UI) I rebooted the machine through the web UI and everything came up correctly. That was a scary few days where I wasn't sure if it was working or not but it appears it was all fine and just some UI glitch. Bottom line if your UI looks like my screenshot above then just ride it out until the rebuild is complete then reboot your server.

Just noticed a drive was emulated so I wrote down which drive was bad, stopped the array, shutdown the server, replaced the drive (with a bigger one 5->8TB), turned back on the server. The array started automatically (wasn't expecting that) with the drive marked as missing. I stopped the array and then assigned the new drive to the missing slop and hit "start" on the array. The page refreshed but all the drives still showed as dropdowns (like I could assign them. Picture: https://www.dropbox.com/s/diymtovifemqemb/Screenshot 2019-09-04 17.47.18.png?dl=0) and the only options at the bottom of the page are "Reboot" and "Powerdown". In the bottom status bar it shows: Array Stopped•Parity-Sync / Data-Rebuild 0.1 %•stale configuration (Note it is now up to 0.3% so it IS doing something). I've never seen this before and in the past when I need to rebuild a drive the bottom section is expanded and show %, time, MB/s, MB total rebuilt, etc. I googled around but couldn't find anyone describing what I'm seeing. I have attached my diagnosis. I'm going to leave the server alone but I'm not sure what the stale config error means and if I need to stop the rebuild and do something else first. tower3-diagnostics-20190904-1741.zip

Thanks! Restarting the array fixed the messages. If they happen again I'll track them back to the start in syslog.

Filesystem Size Used Avail Use% Mounted on tmpfs 128M 79M 50M 62% /var/log /dev/sda1 7.5G 208M 7.3G 3% /boot /dev/md1 4.6T 3.8T 776G 84% /mnt/disk1 /dev/md2 4.6T 3.8T 841G 82% /mnt/disk2 /dev/md3 4.6T 3.7T 918G 81% /mnt/disk3 /dev/md4 4.6T 4.2T 428G 91% /mnt/disk4 /dev/md5 4.6T 2.6T 2.1T 56% /mnt/disk5 /dev/md6 4.6T 2.8T 1.8T 62% /mnt/disk6 /dev/sdb1 236G 45G 187G 20% /mnt/cache shfs 28T 21T 6.7T 76% /mnt/user0 shfs 28T 21T 6.9T 76% /mnt/user /dev/loop0 10G 5.1G 3.8G 58% /var/lib/docker /dev/loop1 1.8M 85K 1.6M 6% /etc/libvirt

If I click the "Log" button in the web UI I see a ton of these messages: Jul 18 00:01:46 Tower shfs/user: share cache full Jul 18 00:01:48 Tower shfs/user: share cache full Jul 18 00:01:48 Tower shfs/user: share cache full Jul 18 00:01:49 Tower shfs/user: share cache full Jul 18 00:01:49 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:50 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:53 Tower shfs/user: share cache full Jul 18 00:01:54 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Jul 18 00:01:55 Tower shfs/user: share cache full Both googling and searching the forums didn't bring up anything. Should I be worried about this? What does it mean? Thanks!

There was a slight change in Kode's application feed which caused that. The system was working correctly with the feed as it was on 7/15. Sometime on 7/16 the feed changed (The notice that the feed was changing probably got lost in a PM along the line) Since you were running in the appFeed mode, you could have reverted back to the old template mode and it would have worked correctly. (Or, with the update 7/16, hit Update Applications, and the error would have fixed itself) Thanks for this! I didn't see the error but when I went to add an application the add container page would be empty instead of prefilled. Clicking the "Update Applications" on the Docker tab for CA worked and now I can add applications again.

I'm having the same problem. I did a "docker attach $containerId" to get the url (didn't think to look in the logs) to do oauth with and then restarted the container after I got it linked and now all I can get is that message. EDIT: It would appear this is the issue it's a pull request on gfjardim's github for the dropbox container. It was post 15 days ago and it's a 1 line (ok technically 2 line) fix and hopefully gfjardim will merge it soon and trigger a rebuild of the container so we can update. EDIT 2: Ok if you are getting the error above causing your container to die 2 seconds after starting then until gfjardim accepts the pull request you can just edit the docker container (from web UI), toggle Advanced View, and change the repository to "joshstrange/unraid-dropbox", then press Save. I am not planning on providing any support whatsoever and offer no guarantees it will work for you but it works for me. Know that this is only a stopgap until the pull request is merged then you can go back to using gfjardim's repo.