Can't create snapshots anymore after successful disk expansions -> "Failed to create snapshot"

[Bombenbodo]

Hi all,

I recently expanded our Raid 6 setup from 4x3TB to 4x10TB which worked as expected. Snapshots were pruned before due to full disks - now after the expansions I was surprised to see that snapshots still got 0% of the overall disk volume even it is enabled to do a hourly snapshot. Creating a snapshot manually resulted into an "Failed to create snapshot" error message.

status.log

[18/02/12 12:37:13 CET] warning:snapshot:LOGMSG_SNAPSHOT_CREATE_WARN Failed to create snapshot initial for share or LUN 'eguoffice'.

system.log

Feb 12 12:37:13 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:13 io snapperd[3394]: reading failed
Feb 12 12:37:13 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:13 io snapperd[3394]: CAUGHT: stat on info directory failed
Feb 12 12:37:13 io msmtpq[8822]: mail for [ -C /etc/msmtprc barsch@egu.eu --timeout=60 ] : send was successful
Feb 12 12:37:45 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:45 io snapperd[3394]: reading failed
Feb 12 12:37:45 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:45 io snapperd[3394]: reading failed
Feb 12 12:37:45 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:45 io snapperd[3394]: reading failed
Feb 12 12:37:45 io snapperd[3394]: THROW: stat on info directory failed
Feb 12 12:37:45 io snapperd[3394]: reading failed

Any ideas?

Thanks,

Robert

[StephenB · Accepted solution]

---

wrote:

creating test share & manual snapshot works

---

That suggests that if a better solution doesn't emerge, that a brute-force approach should work.

• create a temp share (matching the access settings)
• copy the files into it (perhaps with a backup job)
• delete the original share
• rename the temporary share to match the original

Have you checked to see if this issue affects all your shares, or if it only affects some of them?

[StephenB]

What firmware are you running?

Can you try creating a test share, and see if snapshots work correctly on it?

[Bombenbodo]

creating test share & manual snapshot works

[Bombenbodo]

firmware 6.9.2

[StephenB · Accepted solution]

---

wrote:

creating test share & manual snapshot works

---

That suggests that if a better solution doesn't emerge, that a brute-force approach should work.

• create a temp share (matching the access settings)
• copy the files into it (perhaps with a backup job)
• delete the original share
• rename the temporary share to match the original

Have you checked to see if this issue affects all your shares, or if it only affects some of them?

[Bombenbodo]

yeah it effects all existing shares - if there is no better solution I will go for the brute force suggestion - thanks for the help!

[Bombenbodo]

after moving all files into antother share I am not able to delete the old share - I tried resetting permissions etc. but still no success - the error messages are the same in the logs:

Feb 12 16:51:21 io snapperd[3336]: THROW: stat on info directory failed
Feb 12 16:51:21 io snapperd[3336]: reading failed

[StephenB]

Likely you will need Netgear's help on this.  They might offer to take a look at your system here, but you might need to use paid support.

Alternatively start over (either factory default, or destroy/recreate the volume) and restore all the data from backup.  Painful, but guaranteed.