This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
Hi all,
I have updated my system to be running Firmware 6.4.0-T147, and I have noticed that my shares do not seem to be generating snapshots at all anymore.
All of the shares have an "Hourly" schedule for the snapshots, and none of them have "Allow Snapshot Access" enabled. In the timeline I have no snapshots, and the btrfs command also shows no snapshots:
root@XXXXX:~# btrfs subvolume list -p /Data ID 256 gen 540656 parent 5 top level 5 path .purge ID 259 gen 511528 parent 5 top level 5 path home/XXXXX ID 4878 gen 543084 parent 5 top level 5 path .mail ID 4884 gen 464830 parent 5 top level 5 path home/admin ID 4885 gen 541713 parent 5 top level 5 path Media ID 4886 gen 540832 parent 5 top level 5 path ._share ID 5081 gen 541711 parent 5 top level 5 path btsync ID 5530 gen 543071 parent 5 top level 5 path .timemachine ID 5532 gen 541711 parent 5 top level 5 path Transmission ID 26655 gen 540676 parent 5 top level 5 path barracuda
As I understand it, the snapper program is responsible for snapshots, but it doesn't seem to be working?
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
OK. So after much investigation, it looks like when I run snapperd manually, after a period of time it just decides to stop. It looks like after two minutes of inactivity. It turns out that this is perfectly normal behaviour.
The problem in my case is that dbus seems incapable of starting snapperd up again, failing with the message (in /var/log/daemon.log):
Oct 28 14:29:43 XXX dbus[2117]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Oct 28 14:29:43 XXX dbus[2117]: [system] Activated service 'org.opensuse.Snapper' failed: Failed to execute program org.opensuse.Snapper: Success
Oct 28 14:29:43 XXX readynasd[2362]: Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed).
later, and now everything works, exactly as expected. So it looks like at some point the executable bit was dropped, and that broke dbus, which in turn broke snapper. It turns out that this is probably not the best option, see below.
Problem solved, and thanks for the help!
The other, better, option, is to reinstall the dbus package. That is a more secure option, as otherwise any user that gets onto your system can gain root. Which means that any local exploit becomes automatically a local root exploit… Note that for me this option was more painful, as I also first had to remove the messagebus user, which is probably what caused the problem in the first place, since the upgrade was getting stuck on the fact that the messagebus user already existed.
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
Hi mdgm,
4.3TB free of 8.17TB.
This is *ahem* a Pro 6.
Logs are sent.
I should also mention, that for a brief period it looks like some stuff works, as I was running snapperd from the command line. I still wasn't getting the hourly snapshots being created though.
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
Customer support is not "courtesy", it's what you guys paid for.
But OK, every thread which could have an answer related to my problems, or the problems many of us are having (SAMBA disconnects, snapshots disappearing).
Also, my thread about this and the beta crew not responding was deleted, so that tells a bit about how this place works.
In what way is a crashed/non WAD unit above and beyond the warranty support?
Software support is free for 90 days after purchase for the RN100 series. After that there is a charge. Hardware warranties are of course longer. Business products currently get free chat support for life, but not the home NAS.
Let's drop this, it has hijacked the thread long enough. As I think you know, I don't work for Netgear.
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
Maybe in the US, but over here in Europe we have at least 1 year warranty on non-consumables (such as batteres) and 3 years of statutory warranty. No matter if it's hardware or software.
But I agree, I'm dropping this. Someone finally answered and that's what I wanted all along.
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
OK. So after much investigation, it looks like when I run snapperd manually, after a period of time it just decides to stop. It looks like after two minutes of inactivity. It turns out that this is perfectly normal behaviour.
The problem in my case is that dbus seems incapable of starting snapperd up again, failing with the message (in /var/log/daemon.log):
Oct 28 14:29:43 XXX dbus[2117]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Oct 28 14:29:43 XXX dbus[2117]: [system] Activated service 'org.opensuse.Snapper' failed: Failed to execute program org.opensuse.Snapper: Success
Oct 28 14:29:43 XXX readynasd[2362]: Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed).
later, and now everything works, exactly as expected. So it looks like at some point the executable bit was dropped, and that broke dbus, which in turn broke snapper.
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
OK. So after much investigation, it looks like when I run snapperd manually, after a period of time it just decides to stop. It looks like after two minutes of inactivity. It turns out that this is perfectly normal behaviour.
The problem in my case is that dbus seems incapable of starting snapperd up again, failing with the message (in /var/log/daemon.log):
Oct 28 14:29:43 XXX dbus[2117]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Oct 28 14:29:43 XXX dbus[2117]: [system] Activated service 'org.opensuse.Snapper' failed: Failed to execute program org.opensuse.Snapper: Success
Oct 28 14:29:43 XXX readynasd[2362]: Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed).
later, and now everything works, exactly as expected. So it looks like at some point the executable bit was dropped, and that broke dbus, which in turn broke snapper. It turns out that this is probably not the best option, see below.
Problem solved, and thanks for the help!
The other, better, option, is to reinstall the dbus package. That is a more secure option, as otherwise any user that gets onto your system can gain root. Which means that any local exploit becomes automatically a local root exploit… Note that for me this option was more painful, as I also first had to remove the messagebus user, which is probably what caused the problem in the first place, since the upgrade was getting stuck on the fact that the messagebus user already existed.
