I have searched all over the Internet, and perhaps I missed the answer to this question, but I still cannot solve it yet. So far, I have successfully mounted my QNAP drive: 1. Make a folder for the mount point: /home/t420/QNAP 2. Edit (after getting root privileges) the /etc/fstab file to include the following: - //192.168.x.xxx/homes /home/t420/QNAP nfs defaults - sudo mount -a - For those who are new at this and trying to learn or those trying to understand what the heck I am doing, this is what I understand of the first line I added: - 1st field is the "block device", the address and folder of the device you are trying to mount. - 2nd field is the mount point folder. - 3rd field is the file system type (nfs in my case). - 4th field are mount point options (using defaults). - 5th field is for the ability of a backup utility to dump the file system, or something like that. I've left that field blank for now. 3. The second line in the fstab file is my attempt to automatically mount the NAS drive. The drive fails to mount automatically, although QNAP appears in the list of drives. If I try to click on the QNAP under the list of drives, I get the message - Unable to mount QNAP mount:/home/t420/QNAP: operation permitted for root only. I am able to manually mount the drive: - If I enter root mode by typing su root, then the password, and then type the following: - ***mount -t nfs 192.168.x.xxx/homes:/home/t420/QNAP*** **See error and correction in my comment below** |===============================================================| To make matters more frustrating, I am now unable to mount the drive manually either. I get the message "can't find in /etc/fstab". I typed the mount command exactly as you see it above (with x's replaced by the appropriate address numbers), and the line in the fstab file also exactly as you see it. It seems that it won't recognize my QNAP folder. I really want to love Linux, but this learning curve is very icy right now. What am I doing wrong here?!? Larry

I have a QNAP HS-251+ NAS with two 3TB WD Red NAS Hard Drives in RAID1 configuration. I'm quite acquainted with Linux and CLI tools, but never used mdadm or LVM so, despite knowing (now) that QNAP uses them, I have no expertise, or even knowledge about how QNAP manages to create the RAID1 assemble. Some weeks ago, during a firmware update, the NAS stopped booting. I'm on my way to solve that problem, but I would like to recover my data before attempting to plug my disks again in the NAS (QNAP HelpDesk has been basically useless). I expected to be able to mount the partition easily simply plugin one of the disks on my laptop (Kubuntu), but that was when I discovered that things were more complex than that. This is the relevant information I managed to extract:

xabi@XV-XPS15:~$ sudo dmesg
[...]
[17272.730964] usb 3-1: new high-speed USB device number 3 using xhci_hcd
[17272.884120] usb 3-1: New USB device found, idVendor=059b, idProduct=0475, bcdDevice= 0.00
[17272.884138] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[17272.884144] usb 3-1: Product: USB to ATA/ATAPI Bridge
[17272.884149] usb 3-1: Manufacturer: JMicron
[17272.884153] usb 3-1: SerialNumber: DCC4108FFFFF
[17272.891498] usb-storage 3-1:1.0: USB Mass Storage device detected
[17272.892117] scsi host6: usb-storage 3-1:1.0
[17273.907765] scsi 6:0:0:0: Direct-Access     WDC WD30 EFRX-68EUZN0          PQ: 0 ANSI: 2 CCS
[17273.908085] sd 6:0:0:0: Attached scsi generic sg2 type 0
[17273.908261] sd 6:0:0:0: [sdc] 1565565872 512-byte logical blocks: (802 GB/747 GiB)
[17273.909041] sd 6:0:0:0: [sdc] Write Protect is off
[17273.909046] sd 6:0:0:0: [sdc] Mode Sense: 34 00 00 00
[17273.909789] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[17273.976961] sd 6:0:0:0: [sdc] Attached SCSI disk
xabi@XV-XPS15:~$

xabi@XV-XPS15:~$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 746,52 GiB, 801569726464 bytes, 1565565872 sectors
Disk model: EFRX-68EUZN0    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Dispositivo Boot Start        End    Sectors Size Id Tipo
/dev/sdc1            1 4294967295 4294967295   2T ee GPT
xabi@XV-XPS15:~$ sudo mount /dev/sdc1 /mnt/
mount: /mnt: special device /dev/sdc1 does not exist.
xabi@XV-XPS15:~$

xabi@XV-XPS15:~$ sudo parted -l
[...]
Error: Invalid argument during seek for read on /dev/sdc
Retry/Ignore/Cancel? i                                                    
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? ok                                                             
Model: WDC WD30 EFRX-68EUZN0 (scsi)
Disk /dev/sdc: 802GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

xabi@XV-XPS15:~$

xabi@XV-XPS15:~$ sudo lsblk 
[...]
sdc      8:32   0 746,5G  0 disk 
xabi@XV-XPS15:~$

Using the free version of a commercial tool (UFS RAID Recovery) I've obtained advanced information about the partitions on the disk: and even recovered the lvm backup config

# Generated by LVM2 version 2.02.138(2)-git (2015-12-14): Fri Feb 11 09:43:53 2022

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing '/sbin/vgchange vg288 --addtag cacheVersion:3'"

creation_host = "XV-NAS"	# Linux XV-NAS 5.10.60-qnap #1 SMP Tue Dec 21 10:57:31 CST 2021 x86_64
creation_time = 1644569033	# Fri Feb 11 09:43:53 2022

vg288 {
	id = "g0F3zh-N3aN-1vEQ-qYU4-6Jhv-xgLC-d4hU43"
	seqno = 199
	format = "lvm2"			# informational
	status = ["RESIZEABLE", "READ", "WRITE"]
	flags = []
	tags = ["PV:DRBD", "PoolType:Static", "StaticPoolRev:2", "cacheVersion:3"]
	extent_size = 8192		# 4 Megabytes
	max_lv = 0
	max_pv = 0
	metadata_copies = 0

	physical_volumes {

		pv0 {
			id = "ZcFzMw-ZgzA-fOr0-FGgI-E3hc-uwKu-GzWSKn"
			device = "/dev/drbd1"	# Hint only

			status = ["ALLOCATABLE"]
			flags = []
			dev_size = 5840621112	# 2.71975 Terabytes
			pe_start = 2048
			pe_count = 712966	# 2.71975 Terabytes
		}
	}

	logical_volumes {

		lv544 {
			id = "NRzjb8-Dgw4-oHSj-rjtF-2e8H-KQZ2-YPRre3"
			status = ["READ", "WRITE", "VISIBLE"]
			flags = []
			creation_host = "NAS0D80FB"
			creation_time = 1494716166	# 2017-05-14 00:56:06 +0200
			read_ahead = 8192
			segment_count = 1

			segment1 {
				start_extent = 0
				extent_count = 7129	# 27.8477 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 0
				]
			}
		}

		lv1 {
			id = "1ND0gN-Lcgx-ALcO-Ui17-hzzg-2soX-LGr1rl"
			status = ["READ", "WRITE", "VISIBLE"]
			flags = []
			creation_host = "NAS0D80FB"
			creation_time = 1494716174	# 2017-05-14 00:56:14 +0200
			read_ahead = 8192
			segment_count = 1

			segment1 {
				start_extent = 0
				extent_count = 705837	# 2.69255 Terabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 7129
				]
			}
		}
	}
}

Despite that, I haven't been able to mount the relevant volume (vg288-lv1). As I said, I'm not familiar with LVM, there are some inconsistencies with what I've seen in other posts (no sdc1 device, parted can't find the partitions, the reported size doesn't match the real one...) and I'm not sure how to start to solve this methodically. I've tried using the backup config as a template to restore the lvm volumes and failed, but, as I said, I'm not sure that I'm doing things correctly, so I feel I need some guiding on where to start, as the results of my tests until now will only add confusion. Thanks.

I'm trying to compile QNAP's Linux 5.10 kernel because I need access to their proprietary file system. After fixing (too many) errors I managed to get it to build. However, when I try to but it, I just get a black screen with a flashing cursor. If I remove quiet from the command line, it shows a boot logo and a flashing cursor below it, but again, no prints whatsoever. Journalctl doesn't even acknowledge that the kernel even started to boot. I've also attempted to redirect the output to a serial console but that doesn't show anything either. Where do I even begin?

# Synopsis Healthy Raid-5 array had 1 drive removed, quickly reinserted and started rebuilding. Then a second drive was removed within 10 minutes. Original drive assignments (sda, sdb etc) have changed due to further user errors (rebooting/swapping drives). Need advice on next steps. # Backstory I am sorry this is so long, but here is the backstory if it helps ***************** My name is Mike. I am not a daily user of Linux, but I can work my way through things that I need to get done usually by doing quick searches to remind me of syntax and reading man pages. I thought I could figure this out with time (its been months), and I now realized this is something I am not comfortable doing without help since the data is invaluable to my friends family. He has no other backups of the data since his backup drive also failed and he did not realize it… He just assumed it was working. To start, this is a QNAP appliance that had a 5 drive raid 5 array using 8TB drives. He logged in and noticed that a drive was marked unhealthy due to bad blocks but it was still a member and the array was still working just fine, so he wanted to replace it with a new drive before it got worse. Unfortunately, he pulled out the wrong drive. He quickly realized it was the wrong drive and put it back in, and it started rebuilding on that drive (I saw that in the qnap logs). Without knowing any better, he pulled out the actual drive he wanted to replace within less than 10 minutes and put in a new drive. He noticed the array was offline and his data was inaccessible, so he put the origional drive back in and rebooted the QNAP hoping that would fix it. Obviously, it didn't. He then called, and I said we do not want to do anything until we backup the data that’s on all of the origional drives. He just so happened to have a few 12/18TB external drives that I used dd to clone the md /sdX3 partitions to (not all partitions - /sdX). (Exact commands I used + a note as to which external drive they are on) dd if=/dev/sda3 of=/share/external/DEV3302_1/2024022_170502-sda3.img (DST:18TB-1) dd if=/dev/sdf3 of=/share/DiskImages/2024022_164848-sdf3.img (DST:18TB-2) dd if=/dev/sdb3 of=/share/external/DEV3302_1/2024022_170502-sdb3.img (DST:18TB-1) dd if=/dev/sdg3 of=/share/external/DEV3305_1/2024022_170502-sdg3.img (DST:12TB) dd if=/dev/sdd3 of=/share/DiskImages/2024022_170502-sdd3_Spare.img (DST:18TB-2) These were just quick backups and due to the age of the drives (5+ years) we figured we would also replace all of the NAS drives with new ones. I then repeated this process with each of the drives, one by one except used a process/commands like this: Insert new drive in an empty slot, it got assigned sdh dd if=/dev/sda of=/dev/sdh Wait 14 hours for it to complete, remove the drive, replace with another new drive and repeat. dd if=/dev/sdb of=/dev/sdh Etc… So, we should have exact copies of the drives. I assumed (I think incorrectly) that we could power off the QNAP, swap the old drives out with the copied drives and then we could start trying commands like mdadm -CfR /dev/md1 --assume-clean -l 5 -n 5 -c 512 -e 1.0 /dev/sda3 /dev/sdb3 /dev/sdg3 missing /dev/sdd3 (I am not certain that command is correct even before the next paragraph) Unfortunatly, after swapping the drives we now have two missing drives instead of 1 and the assignments seemed to have changed (ex: sda is no longer sda). I figured I must have messed up a dd copy of a drive, so we were going to start the process over on the missing drive. I tracked which ones were showing/missing, we reinserted the original disks, however now they again have different assignments but it is back to showing only a single missing drive - I am lost. I might be able to figure out the original order by comparing the drive UUID's? But I do not want to touch anything before asking for advice. # Technical description Here is the output of the recommended commands that were supported on the QNAP. [QNAPUser@QNAP ~]$ uname -a Linux QNAP 5.10.60-qnap #1 SMP Mon Feb 19 12:14:12 CST 2024 x86_64 GNU/Linux [QNAPUser@QNAP ~]$ mdadm --version mdadm - v3.3.4 - 3rd August 2015 [QNAPUser@QNAP ~]$ smartctl --xall /dev/sda -sh: smartctl: command not found [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdb /dev/sdb: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdc /dev/sdc: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdd /dev/sdd: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sde /dev/sde: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdf /dev/sdf: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdg /dev/sdg: MBR Magic : aa55 Partition : 4294967295 sectors at 1 (type ee) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdh [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdb3 /dev/sdb3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Name : 1 Creation Time : Thu Aug 17 13:28:50 2017 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 15608143240 (7442.54 GiB 7991.37 GB) Array Size : 31216285696 (29770.17 GiB 31965.48 GB) Used Dev Size : 15608142848 (7442.54 GiB 7991.37 GB) Super Offset : 15608143504 sectors Unused Space : before=0 sectors, after=648 sectors State : clean Device UUID : f49eadd1:661a76d3:6ed998ad:3a39f4a9 Update Time : Thu Feb 29 17:05:02 2024 Bad Block Log : 512 entries available at offset -8 sectors Checksum : d61a661f - correct Events : 89359 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 0 Array State : AAAA. ('A' == active, '.' == missing, 'R' == replacing) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdc3 /dev/sdc3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Name : 1 Creation Time : Thu Aug 17 13:28:50 2017 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 15608143240 (7442.54 GiB 7991.37 GB) Array Size : 31216285696 (29770.17 GiB 31965.48 GB) Used Dev Size : 15608142848 (7442.54 GiB 7991.37 GB) Super Offset : 15608143504 sectors Unused Space : before=0 sectors, after=648 sectors State : clean Device UUID : b50fdcc1:3024551b:e56c1e38:8f9bc7f8 Update Time : Thu Feb 29 17:05:02 2024 Bad Block Log : 512 entries available at offset -8 sectors Checksum : e780d676 - correct Events : 89359 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 1 Array State : AAAA. ('A' == active, '.' == missing, 'R' == replacing) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sde3 /dev/sde3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Name : 1 Creation Time : Thu Aug 17 13:28:50 2017 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 15608143240 (7442.54 GiB 7991.37 GB) Array Size : 31216285696 (29770.17 GiB 31965.48 GB) Used Dev Size : 15608142848 (7442.54 GiB 7991.37 GB) Super Offset : 15608143504 sectors Unused Space : before=0 sectors, after=648 sectors State : clean Device UUID : ae2c3578:723041ba:f06efdb1:7df6cbb2 Update Time : Thu Feb 29 17:05:02 2024 Bad Block Log : 512 entries available at offset -8 sectors Checksum : 70a95caf - correct Events : 89359 Layout : left-symmetric Chunk Size : 512K Device Role : spare Array State : AAAA. ('A' == active, '.' == missing, 'R' == replacing) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdg3 /dev/sdg3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Name : 1 Creation Time : Thu Aug 17 13:28:50 2017 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 15608143240 (7442.54 GiB 7991.37 GB) Array Size : 31216285696 (29770.17 GiB 31965.48 GB) Used Dev Size : 15608142848 (7442.54 GiB 7991.37 GB) Super Offset : 15608143504 sectors Unused Space : before=0 sectors, after=648 sectors State : clean Device UUID : cf03e7e1:2ad22385:41793b2c:4f93666c Update Time : Thu Feb 29 16:38:38 2024 Bad Block Log : 512 entries available at offset -8 sectors Checksum : da1a5378 - correct Events : 80401 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 3 Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing) [QNAPUser@QNAP ~]$ sudo mdadm --examine /dev/sdh3 /dev/sdh3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Name : 1 Creation Time : Thu Aug 17 13:28:50 2017 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 15608143240 (7442.54 GiB 7991.37 GB) Array Size : 31216285696 (29770.17 GiB 31965.48 GB) Used Dev Size : 15608142848 (7442.54 GiB 7991.37 GB) Super Offset : 15608143504 sectors Unused Space : before=0 sectors, after=648 sectors State : clean Device UUID : a06d8a8d:965b58fe:360c43cd:e252a328 Update Time : Thu Feb 29 17:05:02 2024 Bad Block Log : 512 entries available at offset -8 sectors Checksum : 5b32c26d - correct Events : 89359 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 2 Array State : AAAA. ('A' == active, '.' == missing, 'R' == replacing) [QNAPUser@QNAP ~]$ sudo mdadm --detail /dev/md1 (This is the array that is broken)) mdadm: cannot open /dev/md1: No such file or directory [QNAPUser@QNAP ~]$ git clone git://github.com/pturmel/lsdrv.git lsdrv -sh: git: command not found [QNAPUser@QNAP ~]$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md3 : active raid1 sdd3 17568371520 blocks super 1.0 [1/1] [U] md2 : active raid1 sdf3 7804071616 blocks super 1.0 [1/1] [U] md322 : active raid1 sdd5(S) sdf5(S) sde5(S) sdg5(S) sdh5(S) sdb5 sdc5 6702656 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md256 : active raid1 sdd2(S) sdf2(S) sde2(S) sdg2(S) sdh2(S) sdb2 sdc2 530112 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md13 : active raid1 sde4 sdg4 sdh4 sdb4 sdc4 sdf4 458880 blocks super 1.0 [24/6] [_UUUUUU_________________] bitmap: 1/1 pages [4KB], 65536KB chunk md9 : active raid1 sde1 sdg1 sdh1 sdb1 sdc1 sdf1 530048 blocks super 1.0 [24/6] [_UUUUUU_________________] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: [QNAPUser@QNAP ~]$ sudo md_checker Welcome to MD superblock checker (v2.0) - have a nice day~ Scanning system... RAID metadata found! UUID: 29f7c4cf:b6273e81:34f3f156:1cd1cfe2 Level: raid5 Devices: 5 Name: md1 Chunk Size: 512K md Version: 1.0 Creation Time: Aug 17 13:28:50 2017 Status: OFFLINE =============================================================================================== Enclosure | Port | Block Dev Name | # | Status | Last Update Time | Events | Array State =============================================================================================== NAS_HOST 8 /dev/sdb3 0 Active Feb 29 17:05:02 2024 89359 AAAA. NAS_HOST 7 /dev/sdc3 1 Active Feb 29 17:05:02 2024 89359 AAAA. NAS_HOST 9 /dev/sdh3 2 Active Feb 29 17:05:02 2024 89359 AAAA. NAS_HOST 10 /dev/sdg3 3 Active Feb 29 16:38:38 2024 80401 AAAAA ---------------------------------- 4 Missing ------------------------------------------- =============================================================================================== md_checker is a QNAP command, so you might not be familiar with it, but the output should be useful. Based on the output above (**specifically the Last Update Time and Events**), I believe that sdg3 was the first drive to be temporarily pulled from the array and was in the process of rebuilding when the second drive was pulled (now showing as "4 Missing"?) . I believe the second drive is now assigned to sde which is showing Device Role : spare. I am basing this on the the fact that the number of events and Last update time of sdb3, sdc3, sdh3 and sde3 are identical. My goal is to do a recovery using copies of the drives, not the original drives in case something happens to make the issue worse. We do not need the array to be "healthy" or writable since we just need to make a copy/backup of the data. What would be the best way to accomplish this? How can I be certain of the command and order to reassemble the array, and what is the least destructive way to assemble it? I would greatly appreciate any advice I can get, since I am just starting to confuse myself and possibly making the issue worse.

I'm running Debian Bookworm on a TS412 (QNAP); it stores the kernel & initrd in flash. It has a total of 16MB of flash. So even after tweaking with the MD partitions the best I can get is a 12MB initrd . I'm using xz compression. But even so, the initial initrd was 12.5MB. I know the common fix is to reduce modules, but they are not the real issue.

2984    .../usr/lib/modules
6036    .../usr/share
18824   .../usr/lib/arm-linux-gnueabi

Looking in arm-linux-gnueabi it had stuff like libX11... This machine does not even have a console (even getting a serial line is difficult) it certainly does not need "X". So I removed lots of packages totally (apt-get remove ...) in fact rather more than I should really. But the result was a much smaller initrd (about 5MB IIRC) which boots and runs just fine. Problem is, if I ssh onto the box and run say emacs(1) it'd be nice to project the GUI version back to my normal desktop (which has lots of memory and big displays, etc.) but this would require installing the X client libraries on the TS412. Now I don't see why just because I have the package with the X client libraries installed, that a copy needs to be kept on initrd, they aren't needed during boot. Is there a way to limit other stuff from getting onto initrd, not just modules (which are not the culprit) I've already tried document searches for guides to limit initrd.

# Brief context I have a QNAP TS-451. The NAS has failed, but I'm pretty sure the drives are still fine. I have a new QNAP TS-462 to try to replace it and I'd like to ensure my data is intact in the new system. # Question How can I access the contents of the LVM when I cannot assemble the RAID? (more details to the question below) ### Environment The **TS-451** system is dead and no longer boots. It was configured like so: - Drive A - 20TB RAID1 mirror - Drive B - 20TB RAID1 mirror - Drive C - 8TB no RAID - Drive D - 14TB no RAID The **TS-462** is a new system that I want to migrate Drives A/B/C/D to. Separate **Linux system** to (ideally) non-destructively read data from drives A/B/C/D: * Fedora 38 * Linux kernel 6.2.14-300 * Old BIOS (i.e. I do not think it can boot off GPT partitions -- not a problem in this case) * Pentium Dual Core E6500 (just to give you an idea how old this system is) ## Experiment 1 I tried moving one of the drives that is not important (Drive C) to the new TS-462, but it appears that the TS-462 is not able to read it. From what I can tell, it seems confused about the partition table (fdisk reports one thing and blkid/lsblk reports differently. On a separate Linux computer (Fedora 38), I'm able to read the LVM and mount the partition off Drives C & D and confirm the files are intact. ## Experiment 2 So I tried to do the same thing to read off Drive B. Drives A/B are part of a RAID1 mirror, so I figured it should be fine to just experiment (cautiously) on one of the drives and leave the other as backup. Unfortunately, I don't seem to be able to activate the LVM. Here are some of the things I've tried on the Linux system:

# fdisk -l /dev/sdc
Disk /dev/sdc: 18.19 TiB, 20000588955648 bytes, 39063650304 sectors
Disk model: WDC WD201KFGX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DFC9F3CE-9CFA-4251-8DD1-48BF99476C04

Device           Start         End     Sectors   Size Type
/dev/sdc1           40     1060289     1060250 517.7M Microsoft basic data
/dev/sdc2      1060296     2120579     1060284 517.7M Microsoft basic data
/dev/sdc3      2120584 39045853979 39043733396  18.2T Microsoft basic data
/dev/sdc4  39045853984 39046914269     1060286 517.7M Microsoft basic data
/dev/sdc5  39046914272 39063621869    16707598     8G Microsoft basic data

From what I gather from http://www.rodsbooks.com/linux-fs-code/ , the fact the these partitions show up as Microsoft basic data is not a problem, but just evidence that this was setup on a very old version of Linux/fdisk. (I've had the TS-451 since about 2015).

# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 39063650304 sectors, 18.2 TiB
Model: WDC WD201KFGX-68
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 39063650270
Partitions will be aligned on 8-sector boundaries
Total free space is 28423 sectors (13.9 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40         1060289   517.7 MiB   0700  primary
   2         1060296         2120579   517.7 MiB   0700  primary
   3         2120584     39045853979   18.2 TiB    0700  primary
   4     39045853984     39046914269   517.7 MiB   0700  primary
   5     39046914272     39063621869   8.0 GiB     0700  primary

# cat /proc/mdstat 
Personalities : 
md123 : inactive sdc5(S)
      8353780 blocks super 1.0
       
md124 : inactive sdc4(S)
      530124 blocks super 1.0
       
md125 : inactive sdc1(S)
      530108 blocks super 1.0
       
md126 : inactive sdc2(S)
      530124 blocks super 1.0
       
md127 : inactive sdc3(S)
      19521865728 blocks super 1.0
       
unused devices:

# mdadm --assemble --readonly /dev/sdc3
mdadm: device /dev/sdc3 exists but is not an md array.

Why??? :-( pvdisplay and the various LVM tools did not discover the LVMs initially. And when specifying the partition explicitly:

# pvdisplay /dev/sdc3
  Cannot use /dev/sdc3: device is an md component

What? But mdadm said it wasn't. :-(

# mdadm --examine /dev/sdc3

/dev/sdc3:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 5a6e38ee:eb6bf302:79856803:58887046
           Name : 1
  Creation Time : Wed Nov 25 03:18:54 2015
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 39043731456 sectors (18.18 TiB 19.99 TB)
     Array Size : 19521865728 KiB (18.18 TiB 19.99 TB)
   Super Offset : 39043733376 sectors
   Unused Space : before=0 sectors, after=1920 sectors
          State : active
    Device UUID : f2a96ebc:996e4231:1576a39a:8606a71c

    Update Time : Sun Mar 26 00:56:13 2023
       Checksum : 893841dd - correct
         Events : 436627


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

Checksum is good. So shouldn't that mean this is a valid RAID partition? (Although the other partitions (even the swap partitions) show valid raid info and checksums, so I don't know what that means.) Let's try a different route... However, by setting md_component_detection=0 in /etc/lvm/lvm.conf, and doing pvscan --cache --devices /dev/sdc, I was able to get at the LVM data...

# pvdisplay /dev/sdc3
  --- Physical volume ---
  PV Name               /dev/sdc3
  VG Name               vg1
  PV Size               18.18 TiB / not usable 0   
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4766080
  Free PE               0
  Allocated PE          4766080
  PV UUID               Xt2uVv-PMCy-oHuK-0UAc-43ZI-z7TH-hHAK7A

# vgdisplay vg1
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  131
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.18 TiB
  PE Size               4.00 MiB
  Total PE              4766080
  Alloc PE / Size       4766080 / 18.18 TiB
  Free  PE / Size       0 / 0   
  VG UUID               oNdjeV-lPuv-PgPR-J11o-zbHQ-X7az-93sr9J

# lvdisplay vg1
  --- Logical volume ---
  LV Path                /dev/vg1/lv544
  LV Name                lv544
  VG Name                vg1
  LV UUID                z1gyiX-FhGG-cTaM-shPx-wZg4-G1xN-b9fS37
  LV Write Access        read/write
  LV Creation host, time NASEFF3AE, 2015-11-25 03:18:56 -0800
  LV Status              NOT available
  LV Size                144.00 GiB
  Current LE             36864
  Segments               2
  Allocation             inherit
  Read ahead sectors     8192
   
  --- Segments ---
  Logical extents 0 to 5119:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    0 to 5119
   
  Logical extents 5120 to 36863:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    1428360 to 1460103
   
   
  --- Logical volume ---
  LV Path                /dev/vg1/lv1
  LV Name                lv1
  VG Name                vg1
  LV UUID                4lsaNW-E4Bg-g93F-ko0a-Ep1m-wHD0-3Hc3Cb
  LV Write Access        read/write
  LV Creation host, time NASEFF3AE, 2015-11-25 03:19:03 -0800
  LV Status              NOT available
  LV Size                18.04 TiB
  Current LE             4729216
  Segments               2
  Allocation             inherit
  Read ahead sectors     8192
   
  --- Segments ---
  Logical extents 0 to 1423239:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    5120 to 1428359
   
  Logical extents 1423240 to 4729215:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    1460104 to 4766079

Yay, so I should be able to mount the drives, right?

# vgchange -ay vg1
  WARNING: PV /dev/sdc3 in VG vg1 is using an old PV header, modify the VG to update.
  device-mapper: reload ioctl on  (253:3) failed: Device or resource busy
  device-mapper: reload ioctl on  (253:3) failed: Device or resource busy
  0 logical volume(s) in volume group "vg1" now active

Hrm... so maybe md_component_detection=0 is not the right approach? ## Experiment 3 Just for thoroughness, I tested foremost, scalpel, and testdisk. These are fine tools, but I feel a bit cumbersome for the current situation. The disks should be perfectly fine and readable... partitions and filesystems intact. I'm assuming there's just some sort of version incompatibility somewhere? # Goal & Question (revisited) My goal is primarily to access my old data (from Drive A/B) one way or another. I don't mind reformatting one of the drives and migrating from another system. Or putting it in the TS-462 if I had any reasonable expectation of being able to access the data. In my current path (along Experiment 2), where I am stuck is figuring out how to get Linux to recognize the RAID? I think I'm going to try [frostschutz](https://unix.stackexchange.com/users/30851/frostschutz) 's excellent suggestion of [copy-on-write overlays](https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file) shared in https://unix.stackexchange.com/questions/728449/recover-files-from-linux-raid1-member-disk-as-bad-as-it-gets . But I'm open to suggestions!

I have a Rasberry PI where I have mounted a QNAP share. This is how it is mounted in /etc/fstab on the PI: //192.168.1.130/Backup/Icloud /home/pi/IcloudPictures cifs username=admin,password=masked,uid=1000,gid=1000 The mount works fine and I can read and write files. I use rsync on the PI to extract some photos from one folder in the mount point to another folder in the mount point - e.g.: rsync -av --include="*/" --include="*.jpg" --exclude="*" /home/pi/IcloudPictures/source/ /home/pi/IcloudPictures/filtered/ When I use -a it will implicit use -t which preserves timestamp - but the issue is that the timestamp of the file in the filtered folder does not get preserved from the source. It gets the current time as the timestamp. This means that rsync will copy all files each time because the timestamp does not match. I can use --size-only to skip time check, but that has its negative sides as well. Why is the timestamp not preserved? Have I mounted the folder incorrectly?

I need help to mount an external drive used on my QNAP TS-230 (latest firmware) to backup data. I set encrypted partition (LUKS) on this drive with a passphrase. I tried to mount that partition on a Linux system but when I enter the passphrase it doesn't work. I read the passphrase is hashed with the QNAP command storage_util --encrypt_pwd pwd= but I have the same problem with the string returned. Anyone have a solution? Thanks. I used the QNAP web interface to init the disk (*single partition, no others*), adding the encryption option. When I run sudo cryptsetup luksOpen /dev/sdb1 crypt_disk, it asks for the passphrase and the response is No key available with this passphrase.. I tried with both password: in clear, and wrapped with the command storage_util.

I have an NFS mount that has recently developed a problem whereby the mounted filesystem can't be traversed: find /media/photos/ runs fine for a while, then degenerates into an infinite loop over some file: /media/photos/2012/07/02/IMG_1180.jpg.xmp /media/photos/2012/07/02/IMG_1180.jpg.xmp /media/photos/2012/07/02/IMG_1180.jpg.xmp /media/photos/2012/07/02/IMG_1180.jpg.xmp ... The server is a QNAP TS-451+ NAS running 5.0.0.1853. The client is a Linux box running Ubuntu 20.04.3 (focal), Linux 5.8.0-43-generic. Some things I've tried, for troubleshooting: - Delete the file that find loops on. If I do that, find /media/photos does the same thing, but loops on some other file. - Run a filesystem check on the NAS. Reboot the NAS. No change. - Check the inode number, in case something was overflowing. df -i /media/photos shows 6553600 inodes total, 294671 used. That doesn't look unreasonable to me. - Run find on other filesystems. /media/photos is the only filesystem that exhibits this problem. I have other NFS-mounted filesystems from the same NAS that are bigger or use more inodes, but they all work fine. - Run find /media/photos on other hosts. - On the NAS itself, running find on the local filesystem works perfectly. - On a Mac running Monterey, find on all NFS-mounted filesystems works perfectly. - Mount the filesystem manually. Normally, /media/photos is mounted by autofs. I tried systemctl stop autofs, unmount all filesystems, then mount -t nfs -o ro mynas:/photos /mnt. Now find /mnt still exhibits the infinite loop problem above. - Check /var/log. I didn't see anything notable, but I'm also not sure what I should be looking for, beside something with the string "NFS" in it. This mount has been working fine for some years. It only failed about a week ago. This seems to have coincided with the QNAP upgrade to QTS 5.0.0.1853 (though I've been updating the client regularly as well). I'm guessing that the QNAP upgrade tickled some bug in Ubuntu's NFS client. I'm not sure how to troubleshoot this, though. And more importantly what to do about it. Some set of NFS options that I'm not familiar with, perhaps, but NFS isn't my forte.

Situation: a QNAP NAS is serving several directories already and I want to change the settings away from no_root_squash to root_squash. * Does performing this impact anything other than user permissions? * Does a remount have to happen on the client side for this to take effect? I would expect it to be transparent to the client, however I can't find an answer on google, not even anything broaching the topic. Can anyone here tell me with certainty?

I had Debian Jessie on a QNAP TS-210 device, which is an arm processes (kirkland architecture). It was running fine for many years, but I needed to use something which required up to date libraries, so I decided to update to Debian 9 (Stretch) since Debian 10 was the last supported distro for my architecture (so I figured upgrading to Debian 9 would be "safer"). At some point attempting to upgrade, something got fudged, and now my nas device doesn't boot at all, just a blinking red light of death. None of the recovery documentation is applicable because I replaced the QNAP firmware with whatever was needed to put Debian on the device. I have no console access to the device, and it does not seem to boot from USB. However, upon booting after pressing the hardware reset button, it does appear to boot into some sort of recovery mode, as I see it obtaining an IPv6 address from the network. Not an IPv4 address at all, but an IPv6 address only. That seems to indicate that the machine has some life in it and is not bricked, and that I may be able to rescue it. I am going to look into making a custom rescue cd that boots silently without input and runs sshd with a preconfigured password so I can access it....but that isn't so much my issue. Say I can access the device while it is in some sort of recovery mode, what do I do to fix the device? Is it a problem with firmware? Or is it nothing to do with firmware and I could just replace the kernel on the harddrive? What can I do to troubleshoot and begin to regain my device?

My Qnap NAS is cursed with a find command that lacks the -exec parameter, so I have to pipe to something. The shell is: GNU bash, version 3.2.57(2)-release-(arm-unknown-linux-gnueabihf) I'm trying to set the setgid bit on all subdirectories (not files) of the current directory. This does not work: find . -type d | xargs chmod g+s $1 Using "$1", "$(1)", $("1") etc. will not work either. They all indicate that chmod is getting passed a directory name containing spaces as two or more parameters (it spits out its standard help message about what parameters are supported). I don't care to use xargs if I don't have to; I think it chokes on long names anyway, doesn't it? These and variants of them do not work: find . -type d | chmod g+s find . -type d | chmod g+s "$1" I've thought of using awk or sed to inject quotation marks but I have to think there's an easier way to do this. What did people do before -exec? (The sad thing is that I probably knew, back in 1995 or so, but have long since forgotten.) PS: Various of these directory names will contain Unicode characters, the ? symbol, etc. They're originally from macOS which is rather permissive. That said, I should probably replace all the ? instances with something like the Unicode character ⁇ so Windows doesn't choke on them. But that's also going to require a similar find operation with this crippleware version of find.

I just got my first QNAP NAS, used to work mostly with Synology before, and I'm currently trying to figure out how the system uses LVM. Mostly out of curiosity. In my specific case, it's a 2 bay NAS that I'm setting up as RAID 1 "storage pool". Within that pool, I created a "thick volume". These naming conventions do seem a bit confusing. When the "storage pool" gets created, QNAP seems to immediately create a LVM thin pool (i.e. a volume) across all of the free space. Any "thick" or "thin" volumes are then created within that pool. Here is the output of vgs and lvs right after the creation of the storage pool and one 250GB thick volume:

# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  vg1    1   3   0 wz--n- 1.81t    0

 # lvs
  LV    VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv1   vg1  Vwi-aot--- 250.00g tp1         100.00
  lv544 vg1  -wi-------  18.54g
  tp1   vg1  twi-aot---   1.73t             14.13  0.03

After I created the volume, I tried to find out where it was mounted but neither mount nor df -h would show that lv1 was mounted. From the web interface, you could already interact with the shared folder in the lv, so clearly it had to be somewhere. dmsetup ls --tree gives more info:

# dmsetup ls --tree
cachedev1 (252:8)
 └─vg1-lv1 (252:7)
    └─vg1-tp1-tpool (252:4)
       ├─vg1-tp1_tmeta (252:0)
       │  └─ (9:1)
       ├─vg1-tp1_tierdata_2 (252:3)
       │  └─vg1-tp1_tierdata_2_fcorig (252:6)
       │     └─ (9:1)
       ├─vg1-tp1_tierdata_1 (252:2)
       └─vg1-tp1_tierdata_0 (252:1)

So, there is a device called cachedev1 in /dev/mapper and it's mounted on /share/CACHEDEV1_DATA. And within here, any "shared folders" will appear. I don't have the knowledge to make sense of this configuration. What is /dev/mapper/cachedev1 exactly? How did lv1 become part of it? And what is the benefit of using it over just mounting the LVM volume directly?

I've just downloaded version 4.3.6 of QNAP QTS operating system. It seems to contain amd64 Linux kernel 4.2.8, initrd and root filesystem, glibc 2.21, Apache 2.4.37, PHP 5.6.38, no Perl, Python 2.7.17rc1, BusyBox 1.24.1, rsync 3.0.7, Bash 3.2.57, tar 1.22, etc., (some of it) compiled with GCC 4.9.2. Size of the downloaded firmware file is 208 MiB, after full recursive decompression it's 582 MiB, and after compression with 7z it's 148 MiB. (The kernel is 6.88 MiB, the initrd is 15.69 MiB, both compressed.) Thus to be able to run the QTS operating system, the QNAP device needs storage of at least 582 MiB. My questions: 1. Which storage device contains the boot and root filesystems on a QNAP NAS such as TS-251+ when it is running the QTS operating system? Is it one of the SATA HDDs or is there some other internal storage such as a flash (or SSD)? (Please note that I'm interested only in devices which are at least 582 MiB in size, thus a smaller flash containing the bootloader only is not what I'm looking for.) 2. If I want to install Debian (running natively as a replacement of QTS) to the QNAP NAS TS-251+, can I install it to an internal storage device, and will it boot and run if the NAS contains 0 SATA devices? How much internal storage space will be available for the ext4 boot+root filesystem? 3. What options do I have to boot Debian from? I guess these: internal storage (if available), SATA HDD or SSD, external USB storage. Are there any other options, such as an extra SD card or non-SATA SSD?

Tabbing gives me ls data but i want something to be shown like x-session-manager , x-terminal-emulator and so on. How can i get list what can i set?

I want to upload files to a shared link (Qnap storage link) using cURL, how can I do this if i have just a password for the shared link , I do not have a username or an account. I have tried

`
$ curl -u 'password' --upload-file file.txt  https://MY_LINK_DIR/file.txt 

`` but it seems , that is not the right way to do this. can anyone help?

Following a previous answer I'm trying to list the files on an FTP server that match a pattern, as shown below event_date=date +%Y%m%d ftp -n XX.XX.XX.XX todays_files.dat

How could it be that I get easily an ip address with Windows 10 network manager and not with simple Linux QNAP NAS System? And not working situation. I tried to renew the ip address manually.

[admin@NAS ~]# dhclient -v eth3
Internet Systems Consortium DHCP Client 4.3.4
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/ 

Listening on LPF/eth3/24:5e:be:35:c3:23
Sending on   LPF/eth3/24:5e:be:35:c3:23
Sending on   Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

$ ethtool eth3

Settings for eth3:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: on (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

I tried to set the network adapter to static with the IP address from Windows. Then I tried ping via ping -I eth3 8.8.8.8 which didn't worked, too. I tried different ports, too - which results in different MAC addresses. I dont know if the QNAP is to stupid to see the router or maybe the router ignores the QNAP. Or Linux dhclient is much different than Windows DHCP so that on windows it works and on linux not. Maybe someone of you have few ideas :) Thanks in Advance!

I have a QNAP server with 8 disks. I have 2 backup/extra disks that are not in use. (I had the money an knew eventually the running ones would need replaced) The full array was across the 8 disks @6TB each... math... but I pretty sure less than 1/3 was currently filled. I had a rep from QNAP work on it and said that with a double disk dive it most likely wont recover. I have faith in the rep in regards to what he is allowed/can do... but.. I have seen things where people pretty much recovered from this type of disaster. My hope is resting on the fact that according to the system all the disks are still good??? Getting a "Bad magic number" / "Couldn't find valid filesystem superblock" This is the device diag output before rep and then after rep: **** BEFORE ****: RAID metadata found! UUID: cccd0319:89c30791:58322cfe:12ed5c64 Level: raid5 Devices: 8 Name: md1 Chunk Size: 64K md Version: 1.0 Creation Time: Mar 23 11:49:45 2017 Status: OFFLINE =============================================================================== Disk | Device | # | Status | Last Update Time | Events | Array State =============================================================================== 5 /dev/sdl3 0 Active Apr 28 08:03:55 2019 3927 AAAAA.AA 6 /dev/sdk3 1 Active Apr 28 08:03:55 2019 3927 AAAAA.AA 7 /dev/sdj3 2 Active Apr 28 08:03:55 2019 3927 AAAAA.AA -------------- 3 Missing ------------------------------------------- 9 /dev/sdh3 4 Active Apr 28 08:03:55 2019 3927 AAAAA.AA 10 /dev/sdg3 5 Active Apr 23 15:03:27 2019 3515 AAAAAAAA 11 /dev/sdf3 6 Active Apr 28 08:03:55 2019 3927 AAAAA.AA 12 /dev/sde3 7 Active Apr 28 08:03:55 2019 3927 AAAAA.AA =============================================================================== **** AFTER ****: RAID metadata found! UUID: a6860c7d:0b020f8d:1a61ec72:4684aeb7 Level: raid5 Devices: 8 Name: md1 Chunk Size: 64K md Version: 1.0 Creation Time: Apr 29 14:08:04 2019 Status: ONLINE (md1) [UU_UUUUU] =============================================================================== Disk | Device | # | Status | Last Update Time | Events | Array State =============================================================================== 12 /dev/sde3 0 Active Apr 29 14:38:42 2019 331 AAAAAAAA 11 /dev/sdf3 1 Active Apr 29 14:38:42 2019 331 AAAAAAAA 10 /dev/sdg3 2 Rebuild Apr 29 14:38:42 2019 331 AAAAAAAA 9 /dev/sdh3 3 Active Apr 29 14:38:42 2019 331 AAAAAAAA 8 /dev/sdi3 4 Active Apr 29 14:38:42 2019 331 AAAAAAAA 7 /dev/sdj3 5 Active Apr 29 14:38:42 2019 331 AAAAAAAA 6 /dev/sdk3 6 Active Apr 29 14:38:42 2019 331 AAAAAAAA 5 /dev/sdl3 7 Active Apr 29 14:38:42 2019 331 AAAAAAAA ===============================================================================

**BACKGROUND DETAILS:** I've inhereted a QNAP TS-459U-RP. I currently have it connected to my home router via an ethernet/rj45 cable. My computer is connected to the same router. How do I access the QNAP from my computer? If I open nautilus and go to + Other Locations, I now see 2 new options under Networks which only become visible if the QNAP is connected to the router and switched on. The 2 options which become avaible in + Other locations are: NASC3C6BC(FTP) NASC3C6BC(SAMBA) --- **THE MESSAGES:** When I click on the 2 options within Nautilus, I get the following messages: For the FTP option I get Opening "qnap-001.local (ftp) You can stop this operation by clicking cancel." Nothing happens if I do not click Cancel. For the SAMBA option I get Unable to access location - Failed to retrieve share list from server: Connection timed out I then Get an OK button. --- **THE RESET BUTTON:** I do not know the username and password. I have checked the manual and it says that I should press the reset button at the back for 3 seconds to reset the admin password and that after 3 seconds it will make a beeping sound. When I press the reset button at the back for 3 seconds or longer, it makes no beeping sound.