Shadow Copy Previous Versions Broke with 9.10 upgrade

[Kuro Houou]

I am now getting this error when viewing the previous versions tab of my CIFS shares in Windows.

FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/v01/Data, failed - NT_STATUS_ACCESS_DENIED.

This was working fine before the upgrade so not sure if this is a bug or what? I tried deleting my snapshots and recreating the jobs and it created new snapshots, I re-linked them in the share properties under Periodic Snap Shot task. But nothing seems to help.

Any Ideas?

 

[dlavigne]

Please create a bug report at bugs.freenas.org and post your issue number here. Include a debug in your report (you can create that using System -> Advanced -> Save Debug).

 

[Kuro Houou]

I filled the bug report. Digging a little more I see this error in my log window in the freenas gui whenever I click the previous versions tab in the folder properties.

Mar 24 12:32:49 FreeNAS kernel: <118>Mar 24 12:32:49 FreeNAS smbd[40385]: access denied on listing snapdir /mnt/v02/.zfs/snapshot
Mar 24 12:32:49 FreeNAS kernel: <118>Mar 24 12:32:49 FreeNAS smbd[40385]: [2016/03/24 12:32:49.473159, 0] ../source3/modules/vfs_default.c:1189(vfswrap_fsctl)
Mar 24 12:32:49 FreeNAS kernel: <118>Mar 24 12:32:49 FreeNAS smbd[40385]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/v02/Movies, failed - NT_STATUS_ACCESS_DENIED.

I then tried to putty into my box, su to my user and was able to view all the files in that directory.. so not sure why its saying access denied :(

 

[Kuro Houou]

Maybe adding more fuel to the fire, but I have been playing with snapshots in general and it appears like they are no longer working at tracking file changes on my /mnt/v01 or /mnt/v02 shares and the directories below. I have set snapshots to every 5 minutes to test with and have deleted multiple files on each mount point. Yet when I go into my list of snapshots, the "used" size is not reflecting the large files I have deleted. Previously they would show up. When browsing the snapshots through the shell, I can see the files are no longer there after the file has been deleted. Just wondering why snapshots seem to be failing in more ways then one now.

 

[Bidule0hm]

Did you try to clone one of the snapshot to see if you can see the deleted file again?

Reported size of snapshots can be very complicated and don't work the way you think it works, don't use it to see if the snapshots have catched the changes or not.

 

[Kuro Houou]

I will have to try and see, I have only used the "previous versions" with shadow copy before to restore data from snap shots. Quick question, if you clone a snapshot, does it only create files on that mount that have changed since that snapshot? So just all the files that I may have deleted in my test? Is that how the clone works? So it would have the directory structure and then below the dirs, the files that were deleted/changed?

 

[Huseyin Yanardag]

Same problem here.

Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951012, 0] ../source3/modules/vfs_shadow_copy2.c:1212(check_access_snapdir)
Mar 24 23:38:37 fs smbd[76563]: user does not have list permission on snapdir /mnt/volume1/shares/.zfs/snapshot
Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951117, 0] ../source3/modules/vfs_shadow_copy2.c:1381(shadow_copy2_get_shadow_copy_data)
Mar 24 23:38:37 fs smbd[76563]: access denied on listing snapdir /mnt/volume1/shares/.zfs/snapshot
Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951161, 0] ../source3/modules/vfs_default.c:1189(vfswrap_fsctl)
Mar 24 23:38:37 fs smbd[76563]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/volume1/shares, failed - NT_STATUS_ACCESS_DENIED.
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951012, 0] ../source3/modules/vfs_shadow_copy2.c:1212(check_access_snapdir)
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: user does not have list permission on snapdir /mnt/volume1/shares/.zfs/snapshot
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951117, 0] ../source3/modules/vfs_shadow_copy2.c:1381(shadow_copy2_get_shadow_copy_data)
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: access denied on listing snapdir /mnt/volume1/shares/.zfs/snapshot
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: [2016/03/24 23:38:37.951161, 0] ../source3/modules/vfs_default.c:1189(vfswrap_fsctl)
Mar 24 23:38:38 fs kernel: <118>Mar 24 23:38:37 fs smbd[76563]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/volume1/shares, failed - NT_STATUS_ACCESS_DENIED.

 

[cyberjock]

Quick question, if you clone a snapshot, does it only create files on that mount that have changed since that snapshot? So just all the files that I may have deleted in my test? Is that how the clone works? So it would have the directory structure and then below the dirs, the files that were deleted/changed?

A snapshot is a "bookmark" of all of the data that existed (file system data and file data) at that point in time. If you have 2 snapshots, both point to *all* of the data that existed at the moment each of the snapshots was created (independently). It's just a bonus if 99% of the data is shared because that means the newer snapshot only truly takes up the space equivalent to the changes since the old snapshot is also protecting the data.

So cloning a snapshot will look exactly like all of the data that was there at the moment of the snapshot being taken, regardless of any other snapshots that exist, existed in the past, or will exist in the future.

 

[Kuro Houou]

A snapshot is a "bookmark" of all of the data that existed (file system data and file data) at that point in time. If you have 2 snapshots, both point to *all* of the data that existed at the moment each of the snapshots was created (independently). It's just a bonus if 99% of the data is shared because that means the newer snapshot only truly takes up the space equivalent to the changes since the old snapshot is also protecting the data.

So cloning a snapshot will look exactly like all of the data that was there at the moment of the snapshot being taken, regardless of any other snapshots that exist, existed in the past, or will exist in the future.

I see, so if I had 6 TB of total space on my volume with one dataset taking up 4 TB for example, I couldn't clone it because it would need another 4 TB to clone that snapshot. Do I understand that right?

 

[cyberjock]

I see, so if I had 6 TB of total space on my volume with one dataset taking up 4 TB for example, I couldn't clone it because it would need another 4 TB to clone that snapshot. Do I understand that right?

Incorrect. The mountpoint is all that would take up space because the data already exists. The clone is simply pointing to all of the data that already exists in the snapshot.

 

[Kuro Houou]

Incorrect. The mountpoint is all that would take up space because the data already exists. The clone is simply pointing to all of the data that already exists in the snapshot.

I see, thank you for clearing that up for me :) So really a clone is just a bunch of pointers, and if something was deleted it just points to wherever that deleted file exists, at least until the snapshot is removed at which point the file would be removed. It does look like the snapshots are working fine and show files that should be there that I had deleted from my volume before as a test. Wonder why the gui doesn't track the size better though, seems like a helpful tool to show how many changes were made in each snapshot.

 

[cyberjock]

There's several reasons. Mostly all of the info you'd ever want to know is in the GUI. It's just not well understood unless you look at it daily. You've got all these numbers that are differentials from the previous snapshot, plus the "full copy" value. If you don't understand all that (and potentially have to add in quotas and reservations to that mix) then it's quickly a lost cause. ;)

 

[Kuro Houou]

Just got the new update with the Shadow Copy bug fix, looks like everything is working good again! Great response FreeNAS team!