NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Could not delete share due to snapshot deletion failure, Code 1004030000 OS6
I have a ReadyNAS 316 OS 6.10.2 with 3x2TiB + 3x4TiB disks so currently at 12TiB. Seem to have a problem with one of my share folders. I am unable to delete a share due to a snapshot deletion error a...
Clearly the file system for the data volume has become corrupted somehow. The most conservative approach is to do a factory default, rebuild the NAS, and restore the data from backup.
If you purchased the NAS (new) between 1 June 2014 and 31 May 2016, then you have lifetime chat support at my.netgear.com. You could try using that if you have it.
SSH is another possibility - using it to manually delete the snapshots and share. You'd log in as root, using the NAS admin password.
You can list the btrfs subvolumes (e.g., shares and snapshots) with btrfs subvolume list /data
Then you can manually delete the ones you want to get rid of with btrfs subvolume delete <path>
You need to use the full name in the path (e.g., it needs to start with /data/OldChive ). When deleting snapshots you need to delete each one independently (something like /data/OldChive/.snapshots/XX/snapshot for each one).
Clearly the file system for the data volume has become corrupted somehow. The most conservative approach is to do a factory default, rebuild the NAS, and restore the data from backup.
If you purchased the NAS (new) between 1 June 2014 and 31 May 2016, then you have lifetime chat support at my.netgear.com. You could try using that if you have it.
SSH is another possibility - using it to manually delete the snapshots and share. You'd log in as root, using the NAS admin password.
You can list the btrfs subvolumes (e.g., shares and snapshots) with btrfs subvolume list /data
Then you can manually delete the ones you want to get rid of with btrfs subvolume delete <path>
You need to use the full name in the path (e.g., it needs to start with /data/OldChive ). When deleting snapshots you need to delete each one independently (something like /data/OldChive/.snapshots/XX/snapshot for each one).
Hey StephenB
First things first, you said the file system is become corrupted, any idea why or how to prevent it happening again?
Onto the current situation...
Thanks... not fixed yet but better understanding. You told me to use "btrfs subvolume list /data" to see what it was I could not before and to know what to delete.
I used that and found:
ID 287 gen 245200 top level 285 path OldChive/.snapshots (and / or)
ID 9439 gen 242748 top level 287 path OldChive/.snapshots/99/snapshot
Being hidden I could not see it before, so YEAH! now I can see what I want to delete. So I did cd data/OldChive/.snapshots
and entered this line
root@XXNASXX:/data/OldChive/.snapshots# rm -rf 99/
but from there I got about a bajillion lines listing each dir and file and
rm: cannot remove '99/snapshot/(each dir and each file of the dir)': Read-only file system
I tried to use the Admin page to try to change the permissions, as well as windows file expoloer but that did nothing helpful. I then used Google to find the Linux command to change the dir and files from R to RW. However, chmod is not part of the OS, and I could not find any other commands.
If this was a Cisco, Dell, or even a dammed Brocade switch or router I could command line that thing with no problem, but I am not as good with Linux as I wish I was.
I looked back at my purchase info, I bought a diskless system off of Newegg on EXACTLY 5/31/2016. I will try during the day instead of evening to use the chat support, however do you know if they will be upset that I have accessed via SSH already? I have this NAS at home btw, maybe I am strange, but I like tech stuff lol.
If the NAS has made the file system read-only, then it has detected something it thinks could go catestrophically wrong if you write more to it. There is really no way around that that I have found than backing up the data while you can, doing a factory default, and re-building.
Hey SandShark
Just wanted to let you know the solution was found, I was ignorantly trying to use “rm” to delete a “SUBvolume”. Subvolume being something I did not even understand was different that a standard dir.
I should have used the command “btrfs subvolume delete” one each dir in the subvolume. I did, after rereading when not tired the first reply by StephenB, the command posted, and it worked perfectly.
FYI to any reading, since I was already in SSH, I went ahead and ran “btrfs balance start /data” and will once complete—and maybe should have first—run “btrfs scrub start /data”.
I had started the scrub in the admin page, then ran SSH balance without thinking. The Scrub ran for a few seconds before it cleared-up the false Snapshot shown in the admin page. Once I saw the balance and scrub were running at the same time and I actually COULD stop just the scrub I did. I hope I didn’t screw anything up by doing that, but will see.
Hmm. Odd that you were getting a "read-only file system" error instead of something that gave a better clue as to the problem. But glad you got it worked out and it was actually something simple.
StephenB I read over your last a little more closely, and kicked myself!
You wrote:
"Then you can manually delete the ones you want to get rid of with btrfs subvolume delete <path>"
and I somehow missed that the first dozen times I read your post. I did EXACTLY as you wrote starting with the longest path first:
(btrfs subvolume delete /data/OldChive/.snapshots/99/snapshot/)
and working down on down to
(btrfs subvolume delete /data/OldChive)
and IT WORKED!
I just ran a Scrup, and that yellow section which was up to 1.7Tb is NOW GONE!
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
