NSA325v2 - Entware-ng - SAMBA - no samba after hot NAS restart

aldapooh

Hi Mijzelf,

thank you for staying with me on this.

1. I started checking the the file system yesterday (from the Administration Web Interface)
   but I cannot say how it completed because today's Web Interface is no longer avialble, neither Twonkly interface.
   I recall that there was a warning that during file system check some net services would be stopped. Apparently it did not come back.
2. I did netstat via Putty Telnet without restarting NAS
   netstat -lptn
   Active Internet connections (only servers)
   Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
   tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1366/cupsd
   tcp 0 0 ::%576072:139 :::* LISTEN 14548/smbd
   tcp 0 0 ::%576072:23 :::* LISTEN 2091/telnetd
   tcp 0 0 ::%576072:445 :::* LISTEN 14548/smbd
3. the output of next step is the following
   cat /proc/2091/cmdline
   telnetd~ #

My next step would be to try to restart NAS via front button now to see if it helps to bring Web Interface and Twonky back.
But I can wait to see if I need to collect more data or logs.

Thanks a lot.

-A

aldapooh

OK, here is an update.
I had accidentally restarted the NAS when trying to unplug the LAN cable.

After the restart the Web Interface and Twonky page are back. But when connecting via WinSCP via FTP I still see no folders.

Repeating the commands from the previous post but after the restart show:

~ # netstat -lptn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 3336/syslog-ng-pkg
tcp 0 0 192.168.0.222:9443 0.0.0.0:* LISTEN 4109/twonkyserver
tcp 0 0 127.0.0.1:9443 0.0.0.0:* LISTEN 4109/twonkyserver
tcp 0 0 192.168.0.222:9001 0.0.0.0:* LISTEN 4109/twonkyserver
tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 4109/twonkyserver
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2145/httpd
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 2145/httpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1838/pure-ftpd (SER
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1366/cupsd
tcp 0 0 0.0.0.0:601 0.0.0.0:* LISTEN 3336/syslog-ng-pkg
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2145/httpd
tcp 0 0 0.0.0.0:59999 0.0.0.0:* LISTEN 3552/busybox-metare
tcp 0 0 ::%577024:80 :::* LISTEN 2145/httpd
tcp 0 0 ::%577024:8082 :::* LISTEN 2145/httpd
tcp 0 0 ::%577024:21 :::* LISTEN 1838/pure-ftpd (SER
tcp 0 0 ::%577024:23 :::* LISTEN 2088/telnetd
tcp 0 0 ::%577024:443 :::* LISTEN 2145/httpd

~ # cat /proc/2088/cmdline
telnetd~ #

aldapooh

I additionally installed dropbear and I can now login via Putty with SSH to NSA325v2.

Still I cannot access folders via Win 11 Explorer or via WinSCP

aldapooh

what else I did:

• i disabled IPv6 on NAS, somehow it was set to Auto
• i set the flag "Prevent NSA From Being Master Browser" on Server Name tab in Administration UI

aldapooh

now I am doing Volume scan without repair flag and it stuck on 20% for quite some time.

is there any tool I can run via Putty to check and repair the file system if it might be a root cause?

aldapooh

I did another restart as after triggering Volume Scan it seems to hang or to perform very slow

FYI = the output of df, so it seems the data is still there on i-data

~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mtdblock8 48896 44384 4512 91% /zyxel/mnt/nand
/dev/sda1 482922 475988 6934 99% /zyxel/mnt/sysdisk
/dev/loop0 138829 122773 16056 88% /ram_bin
/dev/loop0 138829 122773 16056 88% /usr
/dev/loop0 138829 122773 16056 88% /lib/security
/dev/loop0 138829 122773 16056 88% /lib/modules
/dev/ram0 5120 4 5116 0% /tmp/tmpfs
/dev/ram0 5120 4 5116 0% /usr/local/etc
/dev/ram0 5120 4 5116 0% /usr/local/var
/dev/mtdblock4 10240 1516 8724 15% /etc/zyxel
/dev/md0 7690918212 2292169476 5398748736 30% /i-data/52d93469
/dev/md0 7690918212 2292169476 5398748736 30% /usr/local/zy-pkgs
/dev/md0 7690918212 2292169476 5398748736 30% /etc/zyxel/zy-pkgs
/dev/md0 7690918212 2292169476 5398748736 30% /usr/local/apache/htdocs/adv,/pkg
/dev/md0 7690918212 2292169476 5398748736 30% /usr/local/apache/web_framework/data/cache
/dev/mtdblock4 10240 1516 8724 15% /usr/local/apache/web_framework/data/config
/dev/md0 7690918212 2292169476 5398748736 30% /usr/local/apache/htdocs/adv,/res/imdb_poster

aldapooh

could it be that sysdisk is full and this is part of the problem?

/dev/sda1 482922 475988 6934 99% /zyxel/mnt/sysdisk

could it be that syslog is located there?

can I free some space on sysdisk or am I on a wrong path?

Mijzelf

But when connecting via WinSCP via FTP

Ah. That explains how WinSCP could function without ssh. Didn't know it also has an FTP client. The FTP server doesn't show the 'real' data, only a virtual root with shares in it. In that respect it's related to samba.

Now you have dropbear, you can WinSCP via SCP, and you should see the real filesystem.

could it be that sysdisk is full and this is part of the problem?

When I remember well /dev/sda1 only contains a firmware blob, which is loopmounted in the filesystem. That loopmount is through /dev/loop0, which is apparently 138829kB in size. So it's not clear to me why /dev/sda1 has 482922kB data. Maybe you can look at it:

ls -la  /zyxel/mnt/sysdisk/

Unfortunately it's not easy to do a filesystem check. You can only check if the filesystem is not mounted, and as you can see it is mounted 6 times. (The filesystem is in /dev/md0, which is a raid array).

The check in the webinterface unmounts it for you. And yes, then it becomes slow. While checking the disk is 100% utilized, while parts of the firmware and entware are also on the disk. A rotating disk is not very good in multitasking. That's why we have SSD's.

aldapooh

Hi Mijzelf,

cool. Now I used SCP @ WinSCP connection (which did not work until I installed the dropbear) and you are right, I can now see the whole file system in WInSCP which is more convenient.

The output

~ # ls -la /zyxel/mnt/sysdisk/
drwxr-xr-x 3 root root 1024 Nov 12 2022 .
drwxr-xr-x 7 root root 0 Jun 21 2017 ..
drwxr-xr-x 2 root root 12288 Nov 12 2022 lost+found
-rwxrwxrwx 1 root root 338690048 Nov 12 2022 swap_ul6545p
-rw-r--r-- 1 root root 146800640 Nov 12 2022 sysdisk.img

Do you think I can run fsck from command line to see the progress why file system check is so slow via Web Interface? If yes, which parameters would you recommend?

Or is it already worth to look into reset to factory setting?

Or maybe even to copy files into another NAS via WinSCP since at least for now I have my files available?

Regards, -A

Mijzelf

-rwxrwxrwx 1 root root 338690048 Nov 12 2022 swap_ul6545p

OK. That explains that the partition is full. It contains a swapfile. The 99% full is not a reason of concern. The partition contains two files with a fixed size.

Or is it already worth to look into reset to factory setting?

It won't hurt. Even if the problem is caused by a filesystem damage, it won't be worsened by a factory reset. I have been thinking about the filesytem check. I think it can be done this way:

Edit the file /etc/init.d/rc.shutdown, which is the script which is called to shutdown. (And which is on a ramdisk, so every change is reverted on reboot)
Just after the line '/sbin/swapoff' insert the lines

/sbin/telnetd
/bin/sh

The first line starts a telnet deamon, the 2nd is blocking, to stop the shutdown. The inititate the shutdown with 'poweroff'. Your ssh session will close, but shortly hereafter you can login over telnet.
Then you execute

su
umount /dev/md0
e2fsck.new /dev/md0
sync

after which you can hard powerdown the NAS (The data partition isn't mounted)

Or maybe even to copy files into another NAS via WinSCP since at least for now I have my files available?

Of course you can do that, but it's not very convenient for bulk copying. SCP is slow, due to encryption. The SoC of the NAS maxes out at 1.5-2 MB/sec