Derek_

Do you put this on one line, or on two? e.g. Key: --dns= Value: xxx.xxx.xxx.xxx or Key: --dns=xxx.xxx.xxx.xxx

Hiya, this video from SpaceInvaderOne may well answer your questions... https://www.youtube.com/watch?v=hgcFdUIOf5M

I'm not using Proton, but when i tried to open Firefox with a VPN WireGuard config in unRAID, it wouldn't let me via http - i had to use the https IP provided in the docker info. Strangely, i did not have this issue with LibreWolf. May not be the same problem, but i thought i'd put it out there.

My SSH was turned off, so after reboot nothing new appeared. I started SSH and it plonked a bunch of keypairs. Looks like default to me 🙂 Thanks!

A few years ago, i was mucking around with ssh on unRAID (not via a VM). I knew enough to be dangerous, not enough to be smart. I'm not so dangerous now, but also not so smart still 😁 I'm doing a little maintenance and i've noticed that i have some legacy ssh configs that were manually modified (not via the gui), i was also using the "SSH and Denyhosts" plugin to enable multi-user ssh entry (disable root, enable a different user). I'd like to reset everything so it was like it was ootb. I think i deleted the keypair some time ago, but i didn't "reset" the configs and now i wouldn't know what the defaults be - so i don't know what exactly to 'fix'. Are these the only places to look/cleanup? /boot/config/ssh (ssh_config, and ssh keypairs) /etc/ssh/ (sshd_config manually edited. And keypairs) /root/.ssh/known_hosts (symlink > `/boot/config/ssh/root/.ssh` pretty sure i can just delete this file) Can i just delete sshd_config and keypairs? Will re-generate if i re/start ssh via the gui? Thanks 🙂

Update: i suspect my fstabbing had nothing at all to do with it. It's something to do with OpenSnitch's settings. I've had to disable OpenSnitch - at least temporarily to establish the connection. Whereupon i can re-enable it. I think it's time to replace my desktop, it's gotten glitchy... too much fiddling on my part.

Alrighty! So i think i might've had more than one issue. I was trying things for about 1.5 hrs before i posted, and about 1hr after - and by fluke or by brilliance, i think i've solved it. Updates for both Nobara and unRAID confused where the issue might lie I use OpenSnitch (something that blocks/allows stuff). OpenSnitch has not previously caused this issue, so at first i forgot about it. It appears it was a contributing factor. fstab was 'dated' and needed some tweaking. It appears i needed a combination of: Explicit OpenSnitch SMB "allow" rules; and Updated fstab. Here's my updated fstab: //192.168.1.10/Apps /mnt/NAS/Apps cifs credentials=/home/derek/bits'n'bobs/smbcredentials,uid=1000,gid=1001,iocharset=utf8,noperm,vers=3.1.1,rw,noserverino,x-systemd.automount,x-systemd.idle-timeout=3600 0 0 The change that made the actual difference, i think, was replacing: uid=nobody,gid=users,file_mode=0777,dir_mode=0777 With my desktop user's id numbers: uid=1000,gid=1001 But that alone didn't work. I found that communication worked if i disabled OpenSnitch (but this didn't work before i updated fstab). So i created explicit rules to allow SMB (this wasn't needed pre-updates).

Hiya, Everything was fine until a couple of days ago, and i've had the same settings for at least a couple of years now. But now my drives don't map. I'm using Nobara Linux (Fedora-based, doesn't use SELinux) for a while, and my drive mounts have been fine. But i think a recent update to Nobara 43, and perhaps coupled with unRAID to 7.2.2 (i only just updated to 7.x). I've been using the same fstab for a long time. Here's a line from the fstab that has worked for years: //192.168.1.10/Apps /mnt/NAS/Apps cifs username=derek,password=mysupersecretpassword,uid=nobody,gid=users,file_mode=0777,dir_mode=0777,nofail,noperm,vers=3.0,rw,noserverino,x-systemd.automount 0 0 I re-entered my password in unRAID 'users' tab, and then manually navigated via Dolphin > Network > SMB > NAS > Apps. I entered my username/password and it accepted it. Not only that, it accepted it for all the other visible shares (some shares are hidden). Any hidden share did not accept the credentials. Also, even though i could access "Photos" via the manual method described in this paragraph, i couldn't then navigate there via the terminal (/mnt/NAS/Photos). In Dolphin, i get: In Terminal, i get: derek@Nobara-PC:/mnt/NAS$ cd Apps bash: cd: Apps: No such deviceSo, i'm guessing something in the universe of Linux has changed? I did see someone mention that Nobara "now uses systemd mounting" but no more information than that. Perhaps the entry above is not properly compatible with systemd mounting methods? I'm a confused monkey. I'd appreciate any assistance (even if it's just suggestions to improve the fstab entry regardless of fixing the issue).

Hi there, I have a share: Backups. A while ago i was experimenting, and i made another share: backups (lowercase b). This proved to cause some issues, so i removed that lower-case backups share. Everything seemed to be fine after that, so I didn't think anything more of it. I recently upgraded to 7.2.2 (from 7.1.4), and FixCommonProblems found a problem it hadn't previously identified: I had a look at the share, and it there it was - it was actually set to only use the cache, and i can't change it. It looks like there might be some linkage to the "duplicate" backups share (as Linux is case sensitive, i didn't think it would be an issue at the time). It thinks it's not unique (according to the message at the bottom), but there is no longer another share, or directory in /mnt called backups. There hasn't been for several months. And weirdly, most of the data is actually on 'Disk2': So i'm unsure how to best resolve the issue. Of course, i don't want to lose those backups. I was thinking, temporarily rename the directory whatever, say: backups2 and attempt to modify the settings and then rename back to Backups. I'm not sure if that's a 'safe' thing to do in terms of broader unRAID settings, so i'd appreciate your suggestions or assurances. Cheers.

Thanks, and yes, i had to restore/fix my containers.

Oh ok. Makes sense. One must wonder why the original (?) is still implemented the way it is. It includes text for people upgrading from version 5.x which i think implies it hasn't been looked at for many years.

I think it's for the best. The way it handled SSH was really weird (i thought, but i'm not an expert). I think if you want to push things via SSH to unRAID it might be better to utilise a Docker or even VM. Depends what you want, of course, but i've moved away from ssh'ing to unRAID and i've not missed it

Thanks for your post, i too have folder rather than file for my dockers. I followed your procedure successfully with the addition of manually recreating my 'dockernet' custom docker network (which needs to be done before restoring dockers that might use it). I screwed my permissions because i was tired and used the wrong tool ("New Permissions") instead of the right tool ("fix common problems"). In future, an option might be to use Duplicacy to run as root, and backup the whole appdata/docker directories for full restore (including the parent directory). My Duplicacy doesn't run as root, so this isn't currently an option for me but i might change that. 🤔

Sigh. I ran the "New Permissions" tool in unRAID and of course i ran it across all the disks, as it suggests. I neglected to read carefully enough. ☹️ I restored my Dockers thanks to this post: https://forums.unraid.net/topic/177037-completely-screwed-up-ran-new-permissions-on-every-share-including-appdata-now-no-containers-work-with-execution-error-bad-parameter-message/#findComment-1544109 I have also run Fix Common Problems which tells me there's nothing for me to fix. Is there anything anywhere else that might be screwed that i need to attend to? system or domains ? Thanks for any advice offered. EDIT: If you use "search" to find "permissions" it comes up with some OLD tool! If you manually go to Tools > Docker Safe New Permissions - then you're better protected! How should this be reported to devs? "New Permissions" via search:

+1

Like others, i'd suggest using openssh-server or sftp docker, depending on your use-case. I used to use this, but it's been a while now.

Thanks very much for those descriptions. I do want to use Tailscale tunneling, i'm not confident to expose SSH to the interwebs and i've used Tailscale successfully with Duplicacy. It's just that i'm not happy with Duplicacy for server to server backup. It's done well for client to server backup. I guess there's less to transmit. For Tailscale Serve, i'm not sure - wouldn't that have to be a 'yes' to allow Borg to communicate back and forth? Thank you

Hi there. I had been using Borg to backup to my unRAID for a while. But it was pretty janky. It required NerdTools (not supported now) and an SSH plugin which worked in a weird, not normal way. It was a pain when Borg updated, or when Python updated. It was just annoying and far too administratively burdensome. In the end, i decided to use normal Linux as a backup server instead of unRAID because normal Linux behaves... normally. I also have had success with Duplicacy, which is a far easier way to get started. It's been good for Windows desktops. But i have found Duplicacy lacking when it comes to large backups to remote sites. That is, i've had some problems using Duplicacy to backup unRAID itself to a remote site - a few TB. Duplicacy doesn't have server-side help like Borg does. I *love* Borg's ability to check the health of the repository *on the server*! But Dupliacy has the advantage of being able to use SFTP. This makes it easier. I just think it's a little less robust vs Borg. Absolutely fine for clients with 100s of GB to a remote site. Not so good (at least in my experience), with TBs to a remote site. Note that my remote site is a PC at my parent's place. Recently a BorgServer Docker became available. I'm very interested in trying out, but there's basically zero documentation about it's features/configuration. I'm a Docker noob. I have no idea. I'm also a noob with Tailscale and i'm no Linux or Borg guru either! The author doesn't seem very active in the thread either.

Hi can i please have some advice on the Tailscale settings? Specifically: What do these do? If i disable Tailscale SSH, how does borg communicate across-sites? Thanks.

Oh, i hadn't thought of using a pool instead of a UD. Am i correct in thinking that the pool disk would operate very much like the array disks in terms of access (e.g. for Docker), paths (/mnt/user/) etc? If so, that sounds like the ideal. Thank you :)

Hiya, I've recently set up qbittorrent and a couple of 'Arrs. I'm pretty new to it all. I've decided i'd like to move my existing downloads to an Unassigned Device, rather than have it constantly writing to and reading from the array. I had a look at Unbalanced, but it doesn't seem to see Unassigned Devices. So what's the best way to move my directory/sub-directories to the UD? Cheers.

OK, thanks for replying

I did use DU. Is there an accurate way to check it?

Bummer. Thanks though.

As the title says. I'm happy with XFS on the array, i'm not happy with 8gb of Dockers using ~70gb of btrfs snapshots in the btrfs cache. I've created a separate post to ask what, if anything, can be done about that.