NAS 326 problem

Options
13»

All Replies

  • Mijzelf
    Mijzelf Posts: 2,620  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    As you already found, the NAS will recognize raid array from other ZyXEL NAS boxes (also from the 5xx, as long as the volume spans no more than 2 disks).

    That only the default shares are visible is logical, if you know how it works. On filesystem level a share is just a directory. It is the configuration of Samba which makes it a share. And that configuration is not stored on the disk, but on a flash partition. So moving the disks doesn't move the share configuration. Fortunately you can simply create a share from an existing directory in the shares menu.

    If the shares menu is accessible.

    You have to be very fast. The NAS can only be accessed for a very
    short time via the admin interface. Then switch to the control panel as
    quickly as possible, use the Maintenance, Power, "Power on/off schedule"
    menu and turn off the "power control schedule" slider. The NAS then
    remains stable and can be administered normally again.

    So the fact that automatic reboot is enabled triggers the bug, and not the reboot itself? Can you specify any moment for the reboot, or only on full quarters, or something like that? In the latter case, there might be a cronjob firing each quarter which looks if it's time to reboot. If that tasks has a bug making it never end, you are in trouble.

    This must be the solution for
    firmware-update to V5.21(AAZF.15)C0 with hanging NAS (CPU 100% and NAS
    not reachable) afterwardds, if power control schedule was activated
    before.

    I would expect that a factory reset during the short timeslot you described above would also work. (BTW, that factory reset basically erases the flash partition on which the Samba configuration and other configuration is stored.

  • franzk
    franzk Posts: 16  Freshman Member
    First Anniversary 10 Comments Friend Collector
    edited January 9
    Options

    In addition to my own approach (see above), here the suggested help from support (EMEA):

    Reset the device after the firmware update to prevent possible configuration problems.

    https://support.zyxel.eu/hc/en-us/articles/360011340900-Use-the-RESET-button-on-NAS-Series


    After resetting the device, the data in it will not be lost, but you will need to re-enable the previously disabled folders after the reset.

    https://support.zyxel.eu/hc/en-us/articles/360003641279-NAS-Activating-network-shares-again-after-Reset

    After resetting the device, they also recommended to follow the appropriate steps to prevent CPU overload again.

    https://support.zyxel.eu/hc/en-us/articles/360001390314-High-CPU-Issues-on-Zyxel-NAS


    And last but not least, if possible, they recommend backing up the files for safety. Of course, this is the best tipp - but we all know how often we use backup-procedures. 🤭

    Have fun configuring! 😄

  • franzk
    franzk Posts: 16  Freshman Member
    First Anniversary 10 Comments Friend Collector
    Options

    Hi @Mijzelf

    maybe i understood wrong or explained it wrong. This was the Configuration i had activated before, with earlier firmware.

    image.png

    And on the first Friday/Saturday in January 2024 the problems begun.

    The firmwareupdate was in Dezember 2023 after the the 1st dez, which was the first Friday.
    I had more than 4 weeks no Problems with actual firmware!

    You are the guru 😉 - I think you will understand what the problem here is.

    Only after I managed to deactivate this setting, the NAS was permanently available again.
    I think that the defined restart is not logged properly and therefore occurs again and again until the software no longer wants to work and hangs.

  • Mijzelf
    Mijzelf Posts: 2,620  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    You are the guru 😉 - I think you will understand what the problem here is.

    Not really. There are a zillion ways to implement a function like that, and most of them are wrong. I know the scheduled shutdown function could (can?) trigger a boot loop, but I never figured out why. It's hard to reverse engineer the firmware.

    For automatic shutdown I added a function in Tweaks, which have more functions (like don't shutdown when someone is still connected), and AFAIK that nowhere gave troubles. The main defense against boot loops is that it never shuts down in the first half an hour of uptime.

    But your problem is not a boot loop. I can imagine the firmware somehow kills itself by trying to reboot too smart, but in that case a hard reboot should solve the problem, until the next time to reboot.

Categories

Consumer Product Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）