- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
root@XXXXX:/var/log# snapper list-configs
Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed).
and in daemon.log:
Sep 29 00:15:59 XXXXX dbus[2174]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Sep 29 00:15:59 XXXXX dbus[2174]: [system] Activated service 'org.opensuse.Snapper' failed: Failed to execute program org.opensuse.Snapper: Success
Where should I look to further diagnose what is going wrong here?
Cheers,
Mr Grumble
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Finally, I managed to find this message: https://emacstragic.net/error-gdbus-errororg-freedesktop-dbus-error-spawn-execfailed-failed-to-execu...
One
chmod a+x /usr/lib/dbus-1.0/dbus-daemon-launch-helper
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.
All Replies
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
How full is your data volume?
Which model is this on?
Can you send in your logs (see the Sending Logs link in my sig)?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
I think I can see what the problem is.
Sent you a PM.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
Why is almost every thread answered with a PM? That's not the point of a forum.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
@ZaInT wrote:
Why is almost every thread answered with a PM? That's not the point of a forum.
"almost every thread" is an overstatement.
Sometimes a Netgear employee will offer look at the NAS remotely as a courtesy. That requires executing an agreement, and is usually done with PM.
Sometimes there are possibilities that are risky, so posting them in the main forum is not wise.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
@ZaInT wrote:
Customer support is not "courtesy", it's what you guys paid for.
By "courtesy" support I meant support which was not paid for, and which was over and above the warranty support.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
In what way is a crashed/non WAD unit above and beyond the warranty support?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: ReadyNASOS 6.4.0-T147 (Beta 6) and the case of the missing snapshots
@ZaInT wrote:
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Finally, I managed to find this message: https://emacstragic.net/error-gdbus-errororg-freedesktop-dbus-error-spawn-execfailed-failed-to-execu...
One
chmod a+x /usr/lib/dbus-1.0/dbus-daemon-launch-helper
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.
Problem solved, and thanks for the help!
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Finally, I managed to find this message: https://emacstragic.net/error-gdbus-errororg-freedesktop-dbus-error-spawn-execfailed-failed-to-execu...
One
chmod a+x /usr/lib/dbus-1.0/dbus-daemon-launch-helper
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.