You need to expand
(...)to provide a clue as to what is causing the error.
I follow the restic forum and I don't think you have posted there. There are a number of windows users there who use restic (I don't use windows but I do use restic). It really is a more appropriate place to ask this question.
The bad news is it looks like there may be an issue with the wifi. The good news is that is not on OMV issue. I would suggest trying to find a forum that provides help with those wifi cards.
Look at the iperf3 package.
ssh into your nas and execute
apt install iperf3
Install the same package on your computer.
On your computer execute
sudo iperf3 -s
On your nas execute
iperf3 -c computer_ip_address
I have OMV on a Thecus N5550 nas. It is connected to my computer through gigabit ports and a gigabit switch.
Output on my computer was:
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.37, port 33390
[ 5] local 192.168.1.200 port 5201 connected to 192.168.1.37 port 33406
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 940 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec
[ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec
[ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec
[ 5] 10.00-10.00 sec 318 KBytes 819 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
-----------------------------------------------------------On my nas the output was:
Connecting to host 192.168.1.200, port 5201
[ 5] local 192.168.1.37 port 33406 connected to 192.168.1.200 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 956 Mbits/sec 0 393 KBytes
[ 5] 1.00-2.00 sec 113 MBytes 944 Mbits/sec 0 413 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 431 KBytes
[ 5] 3.00-4.00 sec 113 MBytes 943 Mbits/sec 0 431 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec 0 451 KBytes
[ 5] 5.00-6.00 sec 113 MBytes 944 Mbits/sec 0 451 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 0 451 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 451 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 0 451 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 451 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiverYou don't say how you are testing the up/down speeds, but it looks like you are probably using a speedtest web site.
For the computer - OMV test, are you performing the test by transferring data/files. If so and your NAS is equipped with hdd then the speed is a bit more than I would expect to see unless the amount of data is small and the cache is having an influence.
Errors are accumulative, hence no near errors for you. To reset the counters use:
sudo btrfs device stats --reset /dev/sdc1
I can't help you with the errors. As far as /dev/sdb goes, btrfs does not require partitions if the entire disk is used. It can be installed on existing partitions.
I can't help you with this. It appears that this error is usually the result of faulty ram. This link:
Tree checker — BTRFS documentation
explains a bit, and in the "Reporting problems" section the address of the mailing list is given. I would suggest using this before doing any kind of repairs found with google.
The perhaps good new is that there is probably nothing wrong with the drive.
See post #12 in
Initial btrfs setup from the command line should take you anywhere between 15 to 30 minutes. Once you have things set up you don't need to use the command line again unless you wish to add/remove drives or reconfigure settings (raid type, compression, ...).
You might find some useful info in this thread:
A couple of suggestions:
1 - Do a crontab -e from a root login to make sure you didn't included it there by accident.
2 - Make sure that it is not included in the OMV scheduled tasks from the gui.
I'm pretty sure that these are not the cause, but it doesn't cost anything to check.
Other than that it would seem to be a anacron issue. Perhaps you can create a script that doesn't do anything (maybe touch a file) and include it in the weekly folder and see if it gets executed as well as the balance (you should get an email).
anacron will never miss a run, but it is possible the run didn't complete before you shut down.
Try the following:
root@N5550:~# journalctl | grep 'cron.weekly'
Dec 05 06:47:01 N5550 CRON[29847]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --re
port /etc/cron.weekly ))
Dec 07 07:30:05 N5550 anacron[4649]: Will run job `cron.weekly' in 10 min.
Dec 07 08:14:47 N5550 anacron[4649]: Job `cron.weekly' started
Dec 07 08:14:47 N5550 anacron[8465]: Updated timestamp for job `cron.weekly' to 2021-12-07
Dec 07 08:17:17 N5550 anacron[4649]: Job `cron.weekly' terminated (mailing output)
Dec 07 08:17:19 N5550 postfix/smtp[8728]: 4C1E4E7: replace: header Subject: Anacron job 'cron.weekly
' on N5550: Subject: [N5550.local] Anacron job 'cron.weekly' on N5550
root@N5550:~#Following is the mailout from a successful balance:
/etc/cron.weekly/btrfs-balance:
Before balance of /srv/dev-disk-by-label-BTRFS1
Data, single: total=4.45TiB, used=4.38TiB
System, RAID1: total=32.00MiB, used=592.00KiB
Metadata, RAID1: total=10.00GiB, used=6.29GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 13T 4.9T 7.2T 41% /srv/dev-disk-by-label-BTRFS1
Done, had to relocate 0 out of 4563 chunks
flock: getting lock took 0.000008 seconds
flock: executing btrfs
Dumping filters: flags 0x1, state 0x0, force is off
DATA (flags 0x2): balancing, usage=5
Done, had to relocate 62 out of 4563 chunks
flock: getting lock took 0.000007 seconds
flock: executing btrfs
Dumping filters: flags 0x1, state 0x0, force is off
DATA (flags 0x2): balancing, usage=10
Done, had to relocate 0 out of 4501 chunks
flock: getting lock took 0.000007 seconds
flock: executing btrfs
Done, had to relocate 0 out of 4501 chunks
flock: getting lock took 0.000008 seconds
flock: executing btrfs
Dumping filters: flags 0x6, state 0x0, force is off
METADATA (flags 0x2): balancing, usage=5
SYSTEM (flags 0x2): balancing, usage=5
Done, had to relocate 1 out of 4501 chunks
flock: getting lock took 0.000007 seconds
flock: executing btrfs
After balance of /srv/dev-disk-by-label-BTRFS1
Data, single: total=4.38TiB, used=4.38TiB
System, RAID1: total=32.00MiB, used=592.00KiB
Metadata, RAID1: total=10.00GiB, used=6.29GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 13T 4.9T 7.2T 41% /srv/dev-disk-by-label-BTRFS1I'm not an expert on anacron, but with a bit of googling I've found the following. The command (from a root login):
ls -la /var/spool/anacronshould give the cron timestamps, something like:
-rw------- 1 root root 9 Dec 8 08:23 cron.daily
-rw------- 1 root root 9 Dec 8 08:23 cron.monthly
-rw------- 1 root root 9 Dec 7 08:17 cron.weeklywhich shows time timestamps of the jobs when last run. In the above, the weekly jobs should not run again until on/after Dec 15
I went through this thread again and everything you have shown looks correct. If your timestamps are not current I would assume it to be a permissions problem, but using root as the user I don't see how that would be the case.
I bought my first IBM compatible, a portable with dual 5.25" floppy drives, in 1986. With MS-DOS it was a very reliable setup. It's been downhill every since.
Anyways, the sequence you listed should have worked, but maybe there was an error message you missed. Looks like it should work for you now.
root@N5550:~# btrfs scrub status /dev/sdf
scrub status for 3c116019-c3d4-46f4-856c-cd624761c77e
scrub started at Mon Nov 8 07:54:50 2021 and finished after 06:48:19
total bytes scrubbed: 2.38TiB with 0 errorsroot@N5550:~# ls /etc/cron*
/etc/crontab
/etc/cron-apt:
action.d config config.d errormsg.d logmsg.d mailmsg.d mailonmsgs syslogmsg.d syslogonmsgs
/etc/cron.d:
anacron mdadm openmediavault-powermngmt openmediavault-userdefined
e2scrub_all openmediavault-mkrrdgraph openmediavault-rsync php
/etc/cron.daily:
00logwatch logrotate openmediavault-samba-recycle
0anacron openmediavault-check_locked_users passwd
apt-compat openmediavault-cron-apt quota
bsdmainutils openmediavault-flush-mailq samba
dpkg openmediavault-mdadm
locate openmediavault-pending_config_changes
/etc/cron.hourly:
/etc/cron.monthly:
0anacron btrfs-scrub
/etc/cron.weekly:
0anacron btrfs-balance openmediavault-update-smart-drivedbThe above is a complete listing, but the cron.monthly and cron.weekly are the applicable ones.
Quote- 3) Then you would install it to another USB drive -> But I do not even reach the point where the installer lets me choose any target drive.
I have personally experienced frustration with random errors trying to install an OS from a USB drive to the point where I tried it from a different USB drive and had success. The failed drive had successfully had the image written to it and reported no errors on the check, but failed randomly when trying to use it.
If you have not already done so, it might be worthwhile putting the install image on a different drive.
I'm not sure what size flash you have installed. According to:
https://linuxhint.com/install_openmediavault_nas/
you need at least 4G.
For my Thecus N5550 I used the two USB method shown here:
It went OK, so I used one of my 5 bays to install instead to a HDD.
# >>> [openmediavault]
/dev/disk/by-label/BTRFS1 /srv/dev-disk-by-label-BTRFS1 btrfs defaults,nofail,comp
ress=zstd 0 2This is from OMV5 /etc/stab
What if you add a similar line before the
# >>> [openmediavault]
using your parameters. This will not solve your OMV6 issue, but should get you a working setup. With btrfs multidisk setups you only need to reference one drive of the set (and while I have always used the lowest letter it is supposed to work with any letter).
Debian uses Anacreon. See
Leave 3 out. The rest looks good.
QuoteSo background scub is enabled by default? But when initiated manually (or via cronjob) the -B option must be removed?
The command line parameters can be found here:
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub
When I run the command manually, which is only after I do something with the btrfs settings, I don't use the B option, and then I use the status command with watch.
In any case, the referenced maintenance scripts insert the scrub into cron.monthly and the heart of it contains:
run_task btrfs scrub start -Bd $ioprio $readonly "$MNT"-Bd keeps the task running in the cron job (matches what you have) and prints out the stats at the end, which is what you want. The $ioprio sets the -c and -n flags based on the configuration settings, and $readonly sets the readonly flag (which I don't see in the manual so have no idea if it does anything other than what its name implies). If you configure for "auto" the the command is run for each btrfs disk found (the $MNT parameter).
The default configuration does a weekly balance and a monthly balance/scrub .
I don't use defrag (and it's not enabled by default) or trim. You definitely don't need snapshotting.