This is a QS419U II

Thanks!

My situation: at night I run a backup (rsync) of my QNAP to another NAS, so I was looking for a commandline statement that could do this.
Well, there is none standard on your QNAP, and OPKG seems dead as well, so what do you do?

Well if you having an Intel (x64) based QNAP, then you're in luck.
I did find this cool little tool written by GramThanos - super compact and it works on my QNAP (TVS873).

Download the zip file, extract the binary, copy it to your QNAP (I dumped it for now in my Downloads directory) and make it executable:

chmod +x WakeOnLAN

Next you can use it like so:

./WakeOnLAN MACADDRESS BROADCASTADDRESS

Look up the mac address of the device you'd like to wake up, and add "255.255.255.255" (default doesn't seem to work).
All this would then look something like this:

./WakeOnLAN 09:18:ab:d2:ef:9e 255.255.255.255

For backup purposes, always good to look at the original page first, the binary that I used:

Now the challenge is how to monitor progress.

First thing I did is adding a rule to the Notification Center, so I get a notification when a rebuild was completed.
But I'm antsy at times and really want to know how far we are with the rebuild.

With SSH you can execute this to see your progress ...

cat /proc/mdstat

You'll see something like this (I removed the less relevant info), where it shows we're at 38.5%:

...      
md2 : active raid6 sdj3 sdi3 sdd3 sdc3 sde3 sdf3 sdh3 sdg3
      23382380544 blocks super 1.0 level 6, 512k chunk, algorithm 2  
        recovery = 38.5% (1502218752/3897063424) finish=733.2min speed=54433K/sec
      bitmap: 5/30 pages , 65536KB chunk
...

Hope this is helpful to anyone 😁 

Jellyfin is not enabled.

So how do you "enable"  this QPKG?
I found this to be the way to do this:

qpkg_cli --enable Jellyfin

Note that qpkg_cli is a quite power full tool for dealing with QPKG files.

So the Amcrest camera can store recordings and snapshots on a NAS, but it's very unclear how this needs to be setup from looking at the WebUI of the camera.
So some searching finally made me find this description (link) and I'm just posting it here for future reference and/or as a backup.

Short version: It uses a NFS share ... (would never have figured this out by myself)

Long version:

QNAP / NAS

To allow Amcrest cameras to connect to QNAP via NAS connection you will have to enable NFS in the Network and File Services located in the control panel of your NAS. For more information on how to do this, please refer to the information provided below. 

Note: QVR and QVR Pro support most Amcrest camera's as well. Worse case as ONVIF camera's.

Step 1: Please open Control Panel and navigate to Network & File Services > Win/Mac/NFS.

Step 2: Click NFS Service in the new window and enable NFS v2/v3 and/or NFS v4.

Step 3: After the services have been enabled, follow the link “Click here to set the NFS access right of the network share”. You will be taken to the Shared Folders menu.

Step 4: Under the Action column, please click on Edit Shared Folder Permission.

Step 5: In the next window, select NFS host access under Select permission type.

Step 6: NFS access right is disabled by default, here you can enable it first.

Step 7: Click the Add button to add Host / IP / Network and to set their permissions

Allowed IP Address or Domain Name

1. Single server: A valid domain name, hostname, or IP address that can be resolved by a DNS server.
2. Use wildcard characters to specify a series of servers: Use “*” or “?” to specify the string criteria. When you use wildcard characters in a valid hostname, dot (.) is not included in wildcard characters. For example, when you enter *.example.com, one.example.com is counted while one.two.example.com is not counted.
3. IP network: Use a.b.c.d/x. a.b.c.d refers to the network and x refers to number of bits of the network mask, for example, 192.168.0.0/24. Another valid format is a.b.c.d/network mask. In this case, a.b.c.d refers to the network and the following value refers to the network mask setting. For example, 192.168.100.8/255.255.255.0.
4. If using IPv6, enter the IP address and prefix length (ex: 2001::208:9bff:feed:5023/64) for filtering devices and permission settings. If the prefix length is not set, it will refer to a single host IP.
5. Network group: Represented as @group-name; group-name refers to the name of NIS network group.

The Host/IP/Network field will be the local IP address of your Amcrest camera. Please make sure the permission is set to read/write and the squash option is at Squash no users.

Hit Apply after you have finished setting everything up.

IP Camera

After setting up the NFS rule you will need to enter the IP address of your QNAPdevice into the camera's NAS configuration. To do this you will need to access the camera's web user interface (web UI) using a web browser. 

Step 1: In the web UI, click on Setup>>Storage>>Destination and click on NAS in the Path tab. 

Step 2: Click on the NAS tab. Enter the NAS server address and make sure you specify the volume and the folder where the recordings will be sent to. As shown below:

Click Save. 

The events from your camera will be stored in the file station of your NAS. 

This works in a similar way for other NAS devices (Synology for example).

Problem: what is the RTSP link for my older Amcrest IP camera's?

Took me some time to find it, so for my own reference, and maybe for others:

rtsp://username:password@ipaddress:port/cam/realmonitor?channel=1&subtype=0

RTSP URL Breakdown

The bracketed items are variables that you need to input according to your setup.
Explanations of each variable are given below.

username - username of the device
password - password of the device
IPaddress - IP address of the device. If you are not on the same local network, this should be the external IP address of the device's network.
port - RTSP port number (default 554)
channel - channel number of the stream (default "1" - I haven't found any other channels)
subtype - main or sub stream (main = 0, sub = 1)

For me, the backplane issue reveals itself often on boot, seemingly when the system is still "warm" from running just a second ago. So far I've worked around like:
- Never shutdown teh NAS, at best go to sleep mode.
- Make sure you use UPS with your NAS, since power brownouts may kill the power supply and/or MOSFets.

Note: I have experienced this with my TVS-873 (which QNAP replaced for free) and my TS-896 Pro (I am using the sleep trick for now).

Based on Kommisar's post we gave it a shot today and it looks to be working.

Disk 3 is on, and raid is rebuilding.

If you are going to attempt this on your own boards, read and understand Kommisar's post so you can trace your own board.
Verify your problem is identical before trying this solution.

Here is what was needed for my specific scenario (disk 3 failure, eventually leading to no power).

The mosfet that seems to be the issue is on the opposite side, and is labelled 4957AGM. Google for pinouts (datasheet attached below).

That IC contains 2 mosfets.

Tracing the pins looks like one feeds the 12V sata pins and the other feeds the 5V sata pins (at least for bay 3, other bays may need a different fix).

Shorting the source and drain of each will bypass the mosfet and supply power permanently to the sata ports.
One or both could be faulty, in my case it looks like only the 5V fix was needed but we did both.

** You could also just replace the IC with another 4957AGM, although it may still fail again (something caused it to fail originally).

Shorted:

Make these changes at your own risk. Modifying a circuit should be your last resort! RMA it if you are not familiar with what is shown here (or don't have a friend who is!).

Might not hurt to ask QNAP support if they will offer up a replacement board for sale (it's an easy enough swap), assuming they have a solution to the fault.

Thanks Kommisar for the diagnostic work!

Note:
Some QNAP backplanes have jumpers to short the MOSFets.
You'll have to trace them to make sure yours has these jumpers and that they are indeed the right jumpers.
(source)

Datasheet:

Anyhoo - I've seen some interesting commands that may be helpful for others.

CAUTION:
Only use these commands if you know what you're doing.
In general I'd recommend contacting QNAP support and have them look at it.
QNAP has very good support, even for old QNAP (EOL) models!

First of all, all these commands are executed through an SSH (Shell) connection. This old QNAP article or this official QNAP article may be helpful, but then again: if you do not know what an SSH connection is, you'd probably be better off by contacting QNAP support.

Check RAID Status

The easiest way to check the RAID status is done with md_checher, which should be on your QNAP by default (my old QTS4 QNAP and newer QTS5 QNAP had it both installed):

md_checker

In my case this generated a list like this, where the "AAAA.AA." probably indicates trouble as it seems to be missing two spots. 

Welcome to MD superblock checker (v1.4) - have a nice day~

Scanning system...

HAL firmware detected!
Scanning Enclosure 0...

RAID metadata found!
UUID:		aac26467:7ef59f4f:51673f80:8c31584b
Level:		raid6
Devices:	8
Name:		md1
Chunk Size:	64K
md Version:	1.0
Creation Time:	Sep 7 19:53:43 2020
Status:		OFFLINE
===============================================================================
 Disk | Device | # | Status |   Last Update Time   | Events | Array State
===============================================================================
   1  /dev/sda3  0   Active   Feb  8 14:41:00 2024    58609   AAAA.AA.                 
   2  /dev/sdb3  1   Active   Feb  8 14:41:00 2024    58609   AAAA.AA.                 
   3  /dev/sdc3  2   Active   Feb  8 14:41:00 2024    58609   AAAA.AA.                 
   4  /dev/sdd3  3   Active   Feb  8 14:41:00 2024    58609   AAAA.AA.                 
   5  /dev/sde3  4   Active   Feb  8 14:36:42 2024    58422   AAAAAAAA                 
   6  /dev/sdf3  5   Active   Feb  8 14:36:42 2024    58422   AAAAAAAA                 
   7  /dev/sdg3  6   Active   Feb  8 14:36:42 2024    58422   AAAAAAAA                 
   8  /dev/sdh3  7   Active   Feb  8 14:36:42 2024    58422   AAAAAAAA                 
===============================================================================

Check if Disks are Detected properly

As show in my previous post, we can use qcli_storage storage for that:

qcli_storage -d

On my NAS all disks were detected properly:

Enclosure  Port  Sys_Name     Type      Size      Alias          Signature   Partitions  Model  
NAS_HOST   1     /dev/sda     HDD:data  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0
NAS_HOST   2     /dev/sdb     HDD:data  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0
NAS_HOST   3     /dev/sdc     HDD:data  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0
NAS_HOST   4     /dev/sdd     HDD:data  3.64 TB   --             QNAP FLEX   5           WDC WD40EFZX-68AWUN0
NAS_HOST   5     /dev/sde     HDD:free  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0
NAS_HOST   6     /dev/sdf     HDD:free  3.64 TB   --             QNAP FLEX   5           WDC WD40EFZX-68AWUN0
NAS_HOST   7     /dev/sdg     HDD:free  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0
NAS_HOST   8     /dev/sdh     HDD:free  3.64 TB   --             QNAP FLEX   5           WDC WD40EFRX-68N32N0

Check if all disks have RAID (md) information

Next we need to check all disks to see if they have md superblock information:

mdadm -E /dev/sda3
mdadm -E /dev/sdb3
mdadm -E /dev/sdc3
mdadm -E /dev/sdd3
mdadm -E /dev/sde3
mdadm -E /dev/sdf3
mdadm -E /dev/sdg3
mdadm -E /dev/sdh3

Example output of one of my disks:

/dev/sda3:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : aac26467:7ef59f4f:51673f80:8c31584b
           Name : 1
  Creation Time : Mon Sep  7 19:53:43 2020
     Raid Level : raid6
   Raid Devices : 8

 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)
     Array Size : 23382381696 (22299.18 GiB 23943.56 GB)
  Used Dev Size : 7794127232 (3716.53 GiB 3990.59 GB)
   Super Offset : 7794127504 sectors
   Unused Space : before=0 sectors, after=264 sectors
          State : clean
    Device UUID : b8d7db50:63e4ca78:53c5877e:2e946fd0

    Update Time : Thu Feb  8 14:41:00 2024
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : 7b01bedb - correct
         Events : 58609

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AAAA.AA. ('A' == active, '.' == missing, 'R' == replacing)

Manually reassemble the RAID

CAUTION: This step may damage your RAID volume! If unsure: contact QNAP support!

Now, if all disks have md information (Device Role shows Active device #), you can include all these disks (8 in my case) to manually reassemble the RAID (md1) like so:

mdadm -AfR /dev/md1 mdadm -E /dev/sda3 mdadm -E /dev/sdb3 mdadm -E /dev/sdc3 mdadm -E /dev/sdd3 mdadm -E /dev/sde3 mdadm -E /dev/sdf3 mdadm -E /dev/sdg3 mdadm -E /dev/sdh3

Now if a disk is missing (max 1 for RAID 5, and max 2 for RAID 6) then you can skip those in this command.
If you have too many disks missing, or too many disks with missing md information, then you will not be able to use the "mdadm -AfR" command to reassemble the RAID.

Verify and bringing the volume back online

When all that was completed successfully, verify if RAID is online, again with md_checker:

md_checker

If md_checker is showing that the RAID is ONLINE again, then you can the following to recover the storage config:

/ etc/init.d/init_lvm,sh

(remove the space between the slah forward and "etc" - mod_security of the webserver doesn't seem to like it)

You can after that verify if the RAID and volume are good.
If you are not familiar with these commands, then please read up on them before using them.
Some references: pvs, vgs, lvs, df, mount.

md_checker
pvs
vgs
lvs -a
ls -l /dev/mapper/
df
mount

After this, the volume is usually name "/dev/mapper/cachedevX" which mounts to "/share/CACHEDEVX_DATA".
For example the volume such as /dev/mapper/cachedev1 is mounted to path /share/CACHEDEV1_DATA.

You can then verify the content "File Station" or in the Shell with for example:

ls -l /share/CACHEDEV1_DATA/