ReadyNAS Pro 6 general protection fault: 0000 [#2] SMP

[StephenB]

---

@ninjasniper85_ wrote:

Are you familiar with the linux command line?

hmmm

i will say no

i did some python coding at College

Please guide me

---

What you'd need to do is look in the /etc/snapper/configs folder.  The config files in there are simple numbers (0, 1, 2, etc).  One likely refers to /data/ReoLink.  You'd need to find that file and delete it.

You'd start by enabling ssh in the web admin ui. is to enable ssh.  You could try connecting with WinSCP (using SFTP, with the username=root, and the NAS admin password).  That would give you a GUI interface. You could then copy the files to a PC to take a look (I don't recall if WinSCP gives you an option to view them or not).

[ninjasniper85_]

password not working when i try password

[StephenB]

---

@ninjasniper85_ wrote:

password not working when i try password

---

Some services are denied if you use the default admin password.  So if you are doing that, then change it to something else.

[ninjasniper85_]

The Admin And Password is change i try the Admin and New Password won't let me in

[ninjasniper85_]

alright the admin and password account

i change the password 4 times now and the root copy the admin password to the root and still  denied

[StephenB]

---

@ninjasniper85_ wrote:

alright the admin and password account

i change the password 4 times now and the root copy the admin password to the root and still  denied

---

When you enabled ssh, did you check the box next to "Enable Password Authentication"?

[ninjasniper85_]

yes

[StephenB]

---

@ninjasniper85_ wrote:

yes

---

Maybe try disabling it and then enabling it again (making sure that box is checked).

[ninjasniper85_]

do i have to download the SSH key file?

and yes i try that

[StephenB]

---

@ninjasniper85_ wrote:

do i have to download the SSH key file?

---

No.

This is a puzzle, as this works with all my ReadyNAS on both Win10 and Win11.

Have you tried rebooting the NAS? 

[ninjasniper85_]

Have you tried rebooting the NAS? Yes

so Root is Admin on the UI?

So if i change the password on the UI for the Admin should be the same as the Root?

So it work in CMD

but not WinSCP

[ninjasniper85_]

i think it the Port making not work

[StephenB]

---

@ninjasniper85_ wrote:

So if i change the password on the UI for the Admin should be the same as the Root?

---

Yes.  The ReadyNAS software updates the root password to match the admin password when you change it.

---

@ninjasniper85_ wrote:

So it work in CMD

but not WinSCP

---

So SSH now works in CMD?

If so, are you connecting using SFTP with WinSCP?

[ninjasniper85_]

SFTP

IP: your nas ip
Port: 22

Advanced

Environment > Shell

Shell: Sudo su-

Return Code variable: autodetect

i am in now

[ninjasniper85_]

Done i have deleted /etc/snapper/configs  File 0

🙂 will restart nas and let it be for awhile if no errors or freeze up  i will make this as resolved 

Thanks StephenB

[ninjasniper85_]

Uptime Kuma

❌ Your service NAS went down. ❌ Service Name NAS Service URL 192.168.1.2 Time (UTC) 2023-03-19 03:58:28.062 Error PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. --- 192.168.1.2 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 362ms Today at 2:58 PM

✅ Your service NAS is up! ✅ Service Name NAS Service URL 192.168.1.2 Time (UTC) 2023-03-19 03:59:28.539 Ping 6242 ms Today at 2:59 PM

❌ Your service NAS went down. ❌ Service Name NAS Service URL 192.168.1.2 Time (UTC) 2023-03-19 03:59:58.429 Error PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. --- 192.168.1.2 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 396ms Today at 2:59 PM

(i didn't have Ethernet in my room few weeks ago i move rooms so now it back)

[ninjasniper85_]

Mar 19 15:01:22 NASV2842021 apache_access[3672]: Admin session started from 192.168.1.212
Mar 19 15:01:30 NASV2842021 dbus[2964]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Mar 19 15:01:30 NASV2842021 dbus[2964]: [system] Successfully activated service 'org.opensuse.Snapper'
Mar 19 15:01:30 NASV2842021 snapperd[30120]: open for '/etc/snapper/configs/0' failed
Mar 19 15:01:30 NASV2842021 snapperd[30120]: THROW: file not found
Mar 19 15:01:30 NASV2842021 snapperd[30120]: config '0' not found
Mar 19 15:01:31 NASV2842021 msmtpq[30191]: mail [ 1 ] [ 2023-03-14-22.20.15 ] from queue ; couldn't be sent - host not connected

[ninjasniper85_]

Kernal.log

https://pastebin.com/3GZ8JW83

System.log

https://pastebin.com/NDC0hNYY

[StephenB]

I am wondering about the hardware checksum errors.  Did you move the NAS?  Does switching to the other ethernet connection resolve them?

[Sandshark]

OK, so it doesn't like no 0 configuration. 

/etc/sysconfig/snapper contains a list of configurations.  From my experiments, deleing a share doesn't re-arrange the snapper configs, it removes one.  So if you just remove 0 from the list, it should work.

As with any messing with configuration files, it is advisable to back the file up before editing, just in case you make a mistake that makes things worse.

Now, something also schedules these things, and the schedule isn't in the configuration files, so this may not be the last layer of the onion if the removed configuration was enabled with a schedule.

[StephenB]

---

@Sandshark wrote:

/etc/sysconfig/snapper contains a list of configurations.  From my experiments, deleing a share doesn't re-arrange the snapper configs, it removes one.  So if you just remove 0 from the list, it should work.

---

my bad, I forgot to check whether snapper had a list of configs or not.

@ninjasniper85_ - if you edit this file using WinSCP, you will want to open it with Notepad++ (not notepad).  Notepad++ is freeware.  Go into edit->EOL conversion and make sure that is set to Unix (LF) before saving the file.  Notepad++ handles this a bit differently from what I expect - the option you are currently using for the EOL conversion is grayed out.

But I am more concerned about the other errors.  Not sure what is going on, but I am worried it might be hardware related.  The ethernet checksum errors are unusual.  And the recursive general protection fault is still happening.

You could try running a memory test I guess.

[ninjasniper85_]

## Path: System/Snapper

## Type: string
## Default: ""
# List of snapper configurations.
SNAPPER_CONFIGS="2"

[StephenB]

---

@ninjasniper85_ wrote:

## Path: System/Snapper

## Type: string
## Default: ""
# List of snapper configurations.
SNAPPER_CONFIGS="2"

---

Interesting.  Is there a 2 in /etc/snapper/configs?

[ninjasniper85_]

No there was 0  2 i remove the 0 so i think it will be ok now just have to wait 3 days + now to see if the issues happen again

Sorry for not explain was very busy this morning

[StephenB]

---

@ninjasniper85_ wrote:

No there was 0  2 i remove the 0 so i think it will be ok now just have to wait 3 days + now to see if the issues happen again

---

Ok. Though I am thinking that the snapperd problem is a bit of a distraction, and that we haven't sorted out what the real protection fault cause is.

Although painful,

1. backing up the data
2. doing a factory default
3. reconfiguring the NAS
4. and restoring the data from the backup

might be the best step.

If the problem is due to a software issue that crept in, then the default would resolve it.  But if the NAS hardware is failing, it will continue.