QNAP NAS Community Forum

tumbi wrote: ↑Mon Aug 17, 2020 11:16 am ***** SUCCESS *********

I did it! The NAS is now going into standby! At least the Status LED goes off (while the drive lights remain a steady Green).

Hi There,
How are things with the NAS ? is it still entering in standby ? did you discover anything worth mentioning regarding the settings?
Any input would be highly appreciated!
Many Thanks!

razvannicolae wrote: ↑Wed Feb 24, 2021 4:56 am
So in conclusion, if I remember correctly .... I guess I paid arround 600 Eur for the NAS and Hdds but I have built up so much anger that I could pay 1000 EUR right now on some advertising just to share these facts somewhere ...I cannot belive I have this problem with a 600 Euro NAS!!!!!!!!!!!!!!!! ... and to make it worse .....I have a ** 218Play Synology which barely reach 30MB transfer speed over LAN but which is amazingly quiet and responsive and does also this stand-by or spin-down or whatever you want to call it.
I am determined to post this complain on every forum on NAS I could find.

I highly recommend you a Synology, you won't have any of that problems with that, honestly. I have a Synology and a QNAP at home. With my QNAP I was never able to fix that problem, I already gave up. The consequences are, that the hardddrives don't last so long, which makes it everything more expensive.

The only hope is that QNAP will release a new firmware in the future which fixes that problem. Even a reliable workaround would be good, if somebody can find out something, I would be really happy.

All my QNAP dont have a spindown timer for all drives...failure rate of drives is low (2 drives out of more than 20 over 10 years)

get NAS rated drives and they will work in your NAS

I have NAS rated drives (WD Red), but it's still not cool if the NAS is reading and writing on the harddrives 24/7 even if nobody is accessing them.

Just an Update about the problem. I was able to find the reason. It was the rsyslogd (check on the ssh terminal -> "ps aux | grep rsyslogd"). My workaround for now is to kill that service on the ssh terminal with "kill -9 <processnumber>". The harddrives are quiet now

Hi Everybeze, I got the new 453be with Qnap for 2 weeks. I've seen that problem has been since 2008 Based on the messages on the forums. I wrote that to the support team. Maybe it was very heavy but I'm angry that it wasn't resolved all this time. Write in you please not accepted. I am sorry for my English.

My TS-453BE spins down just fine, but always wakes up again after 15 minutes regardless. I've set the spindown delay right down to 5 minutes to test it, and it just cycles through wake-up/spin-down/wake-up (etc.) all the time. It does this even when I disconnect it from the LAN. This happens when there are no BT jobs, open connections, or other jobs running. I've read that some users find their QNAP doesn't spin down with slimserver, but nobody has mentioned it causing this problem. =======>>>>>>>>>>>>>>>>>>>>>> I was using another firm. I have not encountered any such an error (feature). Since 2008, this problem has qnap this problem. How could you remain indifferent to that. This problem is not cute to return this appliance and not to praise certainty. Please don't come to me with ridiculous recommendations such as 7/24 stolen in NAS prayer. Remember that I'm going to this problem until the consumer rights is this imposition of fashions. You are doing m for HDD firms. Mill is not used, most Qnap users are the teacher of the electrical bills wasted by billion dollars.

razvannicolae wrote: ↑Wed Feb 24, 2021 4:56 am I am determined to post this complain on every forum on NAS I could find.

This won't do much for you, as QNAP is not reading them. You'll need to contact them directly.

rob243 wrote: ↑Tue Mar 02, 2021 5:06 pm Just an Update about the problem. I was able to find the reason. It was the rsyslogd (check on the ssh terminal -> "ps aux | grep rsyslogd"). My workaround for now is to kill that service on the ssh terminal with "kill -9 <processnumber>". The harddrives are quiet now

Did it stay dead? Wait a minute and check again.
Killing my rsyslogd also fixed the constant access, however it restarted a minute of so later (looks like it's a monitored daemon) ...notwithstanding this , the disk activity remained low (disk would spindown)

Since then BTW, I've again run into problems spinning down, came back here to find how to turn off the debug option to container station

I'm having the same issues with my new NAS from qnap. I'm working with qnap CS but so far no joy. From what I've found this issue has been around since at least eary 2007 so I'm not hopeful. Going to give it a few more days then it's probably going to go back, for me it's just not usable.
I have verified that a ReadyNAS spins down with no issues.
It seems that the qnap has a crontab with a lot of entries, the ReadyNAS doesn't even have a crontab. The suspicion is that the crontab is kicking off a process causing the disks to continue spinning.

I wrote a couple of tools insomnia-check.sh & insomnia.sh, they used hdparm -C to check the disks wakefulness.

Sadly the QNAP version of hdparm(1) has logging set so it causes the disks to spin up when used.

I did write a "version" of "hdparm -C" which just did this one thing without waking the disk. This would allow you to monitor the disks long term .

When I get some time , I'll use the QNAP dev tools to make it into something folks can use. The idea is you get a warning a couple of days after a change that caused insomnia (often a QNAP upgrade) that disks are no longer sleeping. Gives you a late (but hopefully prompt) warning tat something broke.When I manage to pack it up, I'll post (won't be soon, sorry , busy on other stuff)

@graemev,
Would it be possible for you to post the raw scripts and hdparm executable somewhere?

OK, I've attached a gzipped tar of the work in progress.

The binaries built there were built using a NATIVE compile on my 64bit Debian box (called real, in the example) ...suggest you ignore these.

hdparm-C.c works like running "hdparm -c" but without the logging issues.
disk_state.c is about a minimal as I can get it . It prints NOTHING , just sets return codes . [an attempt to avoid a dependency on libc ]

Both of the above are "really bad code" (so don't use as an example) but in a wickedly sneaky fashion . They are the result of tracing the hdparm code in action and extracting the single ioctl(2) needed ...but without using ANY libraries. Since ioctl calls are simply a few magic numbers sent to a driver inside the kernel all you need to is "trigger the existing magic" so there's no real logic here.

(the result is that the version compiled on my box [12K in size] actually runs on the QNAP (AMD64) ...see the *.notes files)


insomnia,sh needs to run all the time (with suitable tweeks for sleep time as required) ...I note this script is still using /sbin/hdparm -C ...so need to mod to use disk_state or hdparm-C

insomnia-check.sh needs to be kicked off by cron (or otherwise) once per day

...for more details , as they say "Use the source Luke!"