I have been having issues with my Asustor Nas 6706 for around 5 months now. I have been on with there support for multiple tickets and each one show one thing and the other shows another. The Nas will randomly become un-responsive for 1-6 mins randomly but usually in the am. Sometimes it doesnt happen But when it does nothing will work. Plex stops responding my docker containers stop working and since docker runs my NPM all my websites go down including Asustor apps. I have been haveing multiple issues which is keeping me from using the M.2 cache. So i cant even use that. But these are the images Support sent one person said it was my docker containers ( which i have been running the same for years and this issue just started after one of there ADM updates). This is his reply and the pic he pasted is attached (promiscuous mode)
Reply by
Tommy Chou
»
Unfortunately, the health record shows that docker casue the system enter to "promiscuous mode", which contributes to unstable for ethernet connection.
Thus, the best solutions to resolve the issue are making data & NAS setings backup and re-initialize the system.
Then he also switched it up and said he found call trace errors indicating see below and attachment (call trace errors)
Reply by
Tommy Chou
»
I found Call-trace errors in the NAS health record, indicating that the memory is occupied by the processed.
Please root NAS to clean up memory first, and see whether NAS returns to noraml.
If not, unfortunately, the volume1 is destroyed (massive wrong in parameters).
Please make data backup, and consider to remove/re-build volume1 or to initialize the whole system.
There has been multiple tickets for this NAS and i tried to get them to replace it as it has been nothing but issues with different things. Still they havent even with all the issues. Its like there waiting for my warranty to expire. (Note. i have had tickets for issues that still are not working since i received this NAS ). But now for my main issue is i need my device up 24/7 and these random freezing and losing connection even if its for 30 seconds is causing backups to fail and connections for users to drop causing downloads and uploads to fail. I am still to this day waiting for a fix that doesnt require me to take my hole server down for days because of an issue that shouldnt have happened as this particular issue wasent a problem in till the update months ago. Also cant even reboot as all it does is freeze. Then requires a hard shut down just to power it on again hopeing it turns back on sucessfully. Any help would be greatly appreciated.
Asustor Nas 6706 randomly un responsive for 1-6 mins
-
- Posts: 37
- youtube meble na wymiar Warszawa
- Joined: Sun Aug 24, 2014 7:32 am
Asustor Nas 6706 randomly un responsive for 1-6 mins
- Attachments
-
- promiscuous.png (518.87 KiB) Viewed 238 times
-
- call trace reports.png (453.05 KiB) Viewed 238 times
- father.mande
- Posts: 1911
- Joined: Sat Sep 12, 2015 2:55 am
- Location: La Rochelle (France)
Re: Asustor Nas 6706 randomly un responsive for 1-6 mins
Hi,
Sure I don't have experience and quality of the support, but this remember me some "old" behavior. even now I have totally abandoned docker as an uncontrolled environment.
Update of ADM are for a large part, linked to identified errors (in Linux not only in Asustor NAS) and especially in network stack, also this CVS refer to some new kernel, so can be apply to old one ... but ... generally works as well.
You used veth driver, build for interconnecting container and host and permit to forward (or map) some I.P. port, BUT you want (or docker) to add promiscuous mode ... this mode is build to work with real interface, to "snif" exchange or to create alternative IP on same adapter (ex etho, etho-1, etc.) so it's strange to apply it to veth (or for survey contents of exchange)
This can create a sort of loop between real and veth interface (depends of the application usage)
In the past a workaround was to :
1 replace veth by macvlan or ipvlan (module are proposed by Asustor), but this require a knowledge and a control of the container and capabilities accepted by it ... BUT clearly the best
2 force BEFORE starting container the real interface (eth0, br0, etc.) to promiscuous mode (ip link), this can't solve container problem but reduce impact on the system by returning a know error to container.
Nothing is sure (you test or not ... it's your choice ) ... as I write here before, I had abandoned docker from a long time and use other solutions even using veth, macvlan or ipvlan.
... so I can't test in a similar env. as you. and don't use it with recent kernel ...
Philippe.
NB my 2 cents ... so I don't participate any more to this topics.
NB2 please add model and ADM version and Application version to the message or in signature.
Sure I don't have experience and quality of the support, but this remember me some "old" behavior. even now I have totally abandoned docker as an uncontrolled environment.
Update of ADM are for a large part, linked to identified errors (in Linux not only in Asustor NAS) and especially in network stack, also this CVS refer to some new kernel, so can be apply to old one ... but ... generally works as well.
You used veth driver, build for interconnecting container and host and permit to forward (or map) some I.P. port, BUT you want (or docker) to add promiscuous mode ... this mode is build to work with real interface, to "snif" exchange or to create alternative IP on same adapter (ex etho, etho-1, etc.) so it's strange to apply it to veth (or for survey contents of exchange)
This can create a sort of loop between real and veth interface (depends of the application usage)
In the past a workaround was to :
1 replace veth by macvlan or ipvlan (module are proposed by Asustor), but this require a knowledge and a control of the container and capabilities accepted by it ... BUT clearly the best
2 force BEFORE starting container the real interface (eth0, br0, etc.) to promiscuous mode (ip link), this can't solve container problem but reduce impact on the system by returning a know error to container.
Nothing is sure (you test or not ... it's your choice ) ... as I write here before, I had abandoned docker from a long time and use other solutions even using veth, macvlan or ipvlan.
... so I can't test in a similar env. as you. and don't use it with recent kernel ...
Philippe.
NB my 2 cents ... so I don't participate any more to this topics.
NB2 please add model and ADM version and Application version to the message or in signature.
Asustor updated
AS6602T / AS5202T / FS6706T / AS3302Tv2
Asustor E.O.L. at A.D.M. 4.0
AS5002T / AS1002T
Asustor past
AS202T
AS6602T / AS5202T / FS6706T / AS3302Tv2
Asustor E.O.L. at A.D.M. 4.0
AS5002T / AS1002T
Asustor past
AS202T
-
- Posts: 37
- Joined: Sun Aug 24, 2014 7:32 am
Re: Asustor Nas 6706 randomly un responsive for 1-6 mins
i appreciate your reply. i will try and figure out what your saying to try as i am not the best but i really thank you for trying to help.
-
- Posts: 37
- Joined: Sun Aug 24, 2014 7:32 am
Re: Asustor Nas 6706 randomly un responsive for 1-6 mins
AS6706T
ADM: 4.3.1.R752
Bios: 1.21
ADM: 4.3.1.R752
Bios: 1.21
- snapshot
- Posts: 214
- Joined: Sat Mar 16, 2013 6:58 am
- Location: Wiltshire, England
Re: Asustor Nas 6706 randomly un responsive for 1-6 mins
My AS6706T is on BIOS 1.22 but I don't know if/when it updated. I know I didn't do it manually.
I don't use Docker so can't help directly but perhaps we can run through some basic checks.
Have you added extra RAM? If so what exactly is it?
Have you checked the SMART data for all the drives to make sure none are failing?
I apologise if these are things you've already checked but it helps to have them confirmed for anyone else looking at your problem.
I don't use Docker so can't help directly but perhaps we can run through some basic checks.
Have you added extra RAM? If so what exactly is it?
Have you checked the SMART data for all the drives to make sure none are failing?
I apologise if these are things you've already checked but it helps to have them confirmed for anyone else looking at your problem.