Thanks Turbo5vz and fbeye! I will look into it during the weekend.
And my apologies to gderf - you are right, initially I wanted to redirect all traffic outside the LAN - but as that seems to be impossible without command line installations, I'll settle for "all bittorrent traffic".
fbeye, thanks for the alternative. But I don't see how you connect to the vpn in the first place. Where is the server to connect to? Where is the token? Do you have another container for that? Can you post that dockerfile als well (preferably NordVPN)?
Turbo5vz, can you post the dockerfile you used with NordVPN?
Hmm, technially it works, but the vpn speeds are extremely slow (often 0).
Downloading the same torrent on my desktop via vpn gives me an acceptable speed (25MBps, around half my bandwidth).
Probably a configuration thing. Must investigate further.
This looks promising:
Im gonna try it and report back.
OK, I can try that. But I am a burnt child regarding installing software from the command line on a NAS. Sometimes the new software breaks something else, sometimes it gets broken by a system update, and of course I have to update it manually. So I would prefer a solution within the OMV framework...
Hi,
I would like to set up my NAS so that all traffic is routed through a VPN tunnel. NordVPN seem a good option, so I am looking for a guide how to set this up. Should I use the Wireguard plugin? A docker service?
Thanks, I'll do that then.
Hi,
On my OMV NAS, I run cronjobs with omv-backup and snapraid. Most of the time, especially after the backup, I get a warning like
Device: /dev/disk/by-id/nvme-***, Temperature 69 Celsius reached critical limit of 55 Celsius (Min/Max 32/78)even though the backup itself only takes a minute. So I'm beginning to wonder if the backup is doing more harm than good, because it makes the system disk overheat on a regular basis. I tried to use the following command line for the cron job:
nice -20 /usr/sbin/omv-backupbut this didn't help, probably because "nice" only affects the relative priority of the backup process, it doesn't lead to a slow down if there are no other processes.
Is there a way to tell omv-backup to work more slowly? I wouldn't mind if the backup took an hour; it runs at night anyway.
Thanks - much appreciated!
Ah, I see. If the same settings are applied to each method, it could be problematic to have "v" as a default parameter.
I added fsarchiver to the plugin three years ago and the verbose flag has always been there. And it only uses one 'v' which is the least amount of verbosity. You are the first to ask for less info.
OK then, two's company... 
I also don't need to know every single file that has been backed up every week. Like "Trottel", I would prefer just getting the info if everything went well or if there were problems (so I don't want to disable the email notification completely). But I keep an archive of my mails, so I would prefer shorter mails.
Would it be possible to move the "v" option into the backup -> settings tab? It could still be default, I would just like to be able to switch it off.
OK, it worked now. I'm down to 70% usage now; let's hope that the size of the logfiles becomes smaller over time. (I just wonder why syncing helped hulmul...)
Thanks again for your help!
You guessed right, it was an initial run (after OMV reinstallation). Thanks for this! I run it manually, about once per month, so it shouldn't be a permanent problem.
However, I'm still wondering why the ramdisk is still full after syncing, and what I can do to ensure that the ramdisk is synced (and purged) more frequently and regularly. Any hints?
Here's the content of /var/log:
-rw-r--r-- 1 root root 3456 Aug 18 12:20 alternatives.log
drwxr-xr-x 2 root root 100 Aug 17 13:06 apt
-rw-r----- 1 root adm 217088 Aug 19 11:17 auth.log
-rw-r----- 1 root adm 269141 Aug 13 00:00 auth.log.1
-rw-r----- 1 root adm 11574 Aug 6 00:00 auth.log.2.gz
-rw-r--r-- 1 root root 0 Jul 24 12:07 bootstrap.log
-rw-rw---- 1 root utmp 768 Aug 8 15:44 btmp
drwxr-x--- 2 _chrony _chrony 40 Jul 31 11:10 chrony
drwxr-xr-x 2 root root 120 Aug 13 00:00 cron-apt
-rw-r----- 1 root adm 2444763136 Aug 19 11:09 daemon.log
-rw-r----- 1 root adm 1198425414 Aug 13 00:00 daemon.log.1
-rw-r----- 1 root adm 49760225 Aug 6 00:00 daemon.log.2.gz
-rw-r----- 1 root adm 2732 Aug 18 12:20 debug
-rw-r----- 1 root adm 7842 Aug 9 16:33 debug.1
-rw-r----- 1 root adm 2221 Aug 3 11:38 debug.2.gz
-rw-r--r-- 1 root root 54829 Aug 17 13:06 dpkg.log
-rw-r--r-- 1 root root 32160 Aug 7 17:14 faillog
-rw-r--r-- 1 root root 0 Jul 24 12:07 fontconfig.log
drwxr-xr-x 3 root root 160 Jul 31 11:07 installer
drwxr-sr-x+ 3 root systemd-journal 60 Jul 31 11:10 journal
-rw-r----- 1 root adm 111932 Aug 18 19:41 kern.log
-rw-r----- 1 root adm 330875 Aug 11 16:34 kern.log.1
-rw-r----- 1 root adm 163110 Aug 5 11:17 kern.log.2.gz
-rw-rw-r-- 1 root utmp 293460 Aug 19 10:02 lastlog
-rw-r----- 1 root adm 12288 Aug 19 08:23 mail.info
-rw-r----- 1 root adm 19662 Aug 11 13:03 mail.info.1
-rw-r----- 1 root adm 14110 Aug 3 11:03 mail.info.2.gz
-rw-r----- 1 root adm 12288 Aug 19 08:23 mail.log
-rw-r----- 1 root adm 19662 Aug 11 13:03 mail.log.1
-rw-r----- 1 root adm 14110 Aug 3 11:03 mail.log.2.gz
-rw-r----- 1 root adm 303104 Aug 19 11:17 messages
-rw-r----- 1 root adm 602901 Aug 12 23:17 messages.1
-rw-r----- 1 root adm 199783 Aug 5 23:17 messages.2.gz
-rw-r----- 1 root adm 0 Jul 24 12:07 monit.log
drwxr-xr-x 2 root adm 460 Aug 19 00:00 nginx
-rw-rw-rw- 1 root root 7981 Aug 19 03:01 omv-backup.log
drwxr-xr-x 2 root root 40 Jul 13 13:14 openmediavault
-rw------- 1 root root 338 Aug 18 12:20 php7.4-fpm.log
-rw------- 1 root root 902 Aug 9 16:33 php7.4-fpm.log.1
-rw------- 1 root root 367 Aug 3 11:00 php7.4-fpm.log.2.gz
drwx------ 2 root root 40 Jul 31 11:10 private
-rw-r----- 1 root adm 0 Aug 14 00:00 rsync.log
-rw-r--r-- 1 root root 471289 Aug 13 11:40 rsync.log.1.gz
drwxr-xr-x 3 root root 60 Jul 31 11:05 runit
drwxr-xr-x 2 root root 80 Aug 6 00:00 salt
drwxr-x--- 3 root adm 880 Aug 19 08:47 samba
-rw-rw-rw- 1 root root 1220 Aug 11 12:32 snapraid.log
-rw-r----- 1 root adm 2445213696 Aug 19 11:17 syslog
-rw-r----- 1 root adm 1199227538 Aug 13 00:00 syslog.1
-rw-r----- 1 root adm 50046040 Aug 6 00:00 syslog.2.gz
-rw-r--r-- 1 root root 0 Jul 24 12:07 tallylog
-rw-r----- 1 root adm 12288 Aug 19 08:23 user.log
-rw-r----- 1 root adm 30469 Aug 12 08:23 user.log.1
-rw-r----- 1 root adm 10549 Aug 5 08:19 user.log.2.gz
-rw-rw-r-- 1 root utmp 34944 Aug 19 10:02 wtmpsyslog and daemon.log contain a lot of entries from backup jobs (USBbackup apparently enumerates every single file).
I have the same problem, but even after the sync, I still get:
Filesystem Size Used Avail Use% Mounted on
folder2ram 8.3G 8.3G 0 100% /var/logWhen I click "sync all", it claims to sync /var/log:
will now sync all mountpoints
sync of /var/log successful!
sync of /var/tmp successful!
sync of /var/lib/openmediavault/rrd successful!
sync of /var/spool successful!
sync of /var/lib/rrdcached successful!
sync of /var/lib/monit successful!
sync of /var/cache/samba successful!Why is the ram disk still full?
And anyway, regularly syncing manually is not a real solution IMO... Isn't there a way to make sure that the ram disk is synced reguarly?
With the "Diff script settings" header it becomes much clearer.
So I agree that the time required to change the design would be better spent on other tasks - like integrating several arrays into the main branch...
Not sure what you mean. scrub frequency only applies to the diff script.
That's precisely what wasn't clear to me. On the settings page, it says "scrub frequency - 7 - units in days". There is no indication that this is only relevant if the diff script on the other page is activated. And I still don't understand how the "7 days" scrub frequency interacts with the scheduling settings from the diff page.
I would find it more intuitive if all settings related to the scheduled diff were on that page. (Just a suggestion)
That should be a random uuid.
Maybe you forgot to call srand()?
QuoteHow are you going to "disable" them?
I figured changing the scrub percentage from "100" to "0" would work.
QuoteThey are used in the diff script AND manual scrub commands in the plugin.
Ah, I didn't know that. In that case, it's a bit confusing that the scrub frequency is on the settings page and the date/time is in the diff sub-page...
QuoteManual runs will never send emails but you do have to have notifications setup for the script if/when it gets fixed.
Good to know.
OK, it's been a while, but now I have installed the new system with two Snapraid arrays. Manual snapraid sync and check jobs work fine so far (without rebuilding the cache, the errors really seem to result from the old system).
BTW, in the new OMV installation, the config file for the first array is called omv-snapraid-114a88d2-53ed-11ed-8eee-b3f2573b9c38.conf again, so it was no accident that it was the same for both of us.
Now I have three remaining questions:
- If I were to to run scheduled tasks using the config files for the different arrays, as in
snapraid -c /etc/snapraid/omv-snapraid-114a88d2-53ed-11ed-8eee-b3f2573b9c38.conf sync ,
this should work, right?
- About the "scrub" configuration in the "Snapraid settings": Should I disable them also (as with the scheduled diff)?
- The "send mail" checkbox in the settings is checked, but I haven't received any mails after the manual syncs / checks. Do I have to do something else? I have setup my mail account in "System Notification"
Maybe I figured something out. My network controller's id is "enp3s0", but in /etc/network/interfaces ist was "enp2s0" (probably because there was only one SATA adapter during installation).
I changed /etc/network/interfaces, and at first glance, it seems to work.
Do I have to worry that the file will be overwritten the next time I change the configuration and press "apply"?