AFP folder path of snapshot folder not correct
I've set up my FreeNAS server to share the dataset through AFP. I've also set the property snapdir to visible for that dataset through zfs set snapdir=visible MyPool/temp (for example).
When I use OS X's Finder application to navigate to .zfs/snapshot/<snapshot name>/<Some Folder In the Dataset>, I somehow get redirected to the current version of that folder.
For example, assume the share is called temp_afp and the folder is called Downloads, then when I browse to /Volumes/temp_afp/.zfs/snapshot/auto-20150218.0900-1w/Downloads, I get redirected to /Volumes/temp_afp/Downloads instead.
Doing some further debugging, I found that the path, displayed by Get Info in Finder is not correct. The same path can be retrieved using the command line tool GetFileInfo.
Have a look at the terminal session below: I'm positioned in a snapshot folder of my AFP share. There are two folders in my snapshot: Downloads and Temp. When I retrieve file information about the Temp folder (for example), it says the directory is "/Volumes/temp_afp/Temp" instead of "/Volumes/temp_afp/.zfs/snapshot/auto-20150218.0900-1w/Temp".
LAMMERJ-M-J0EB:auto-20150218.0900-1w lammerj$ ls Downloads Temp LAMMERJ-M-J0EB:auto-20150218.0900-1w lammerj$ GetFileInfo Temp directory: "/Volumes/temp_afp/Temp" attributes: avbstclinmedz created: 02/17/2015 19:20:35 modified: 02/23/2015 11:37:19 LAMMERJ-M-J0EB:auto-20150218.0900-1w lammerj$
I have this issue with all my FreeNAS 9.3 servers (I have three).
#4 Updated by Jordan Hubbard over 5 years ago
- File Screen Shot 2015-03-12 at 6.06.44 PM.png Screen Shot 2015-03-12 at 6.06.44 PM.png added
- Status changed from Screened to Closed: Behaves correctly
Works just fine! See attached screenshot. I have no problem navigating to the .zfs directory and individual snapshots thereof (though since Finder does not show . files by default, you have to %G your way into that specific directory). Perhaps you have an older version of OS X (I am running Yosemite) that didn't support this properly, or you're getting confused about what path you're actually seeing (show pathbar view preference should be set).
#6 Updated by Joris Lammers over 5 years ago
Have a look at my description: I navigate deeper into the snapshot folder. I can't explain it any more clearer than what I put in the description. I'm copy-pasting my terminal session again below. I basically start at the snapshot folder, then navigate deeper into one of the snapshots and then try to get information of one of the folders (Temp in this case) in that snapshot.
Do you see how the GetFileInfo command returns a completely different path than pwd (last lines of the output below)? If I used Finder (and BTW, I am running Yosemite) to navigate to that Temp folder of the snapshot, I end up viewing the current version and not the older version at the time of the snapshot.
I'm pretty sure the reason GetFileInfo returns a wrong path is way the Finder returns me the latest version of the folder instead of the correct snapshotted version of the folder.
LAMMERJ-M-J0EB:snapshot lammerj$ ls -lh total 0 drwxr-xr-x@ 1 lammerj staff 264B Mar 5 20:06 auto-20150306.1300-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 5 20:06 auto-20150309.0900-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 9 12:56 auto-20150309.1300-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 9 15:31 auto-20150309.1700-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 9 15:31 auto-20150309.2125-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 9 15:31 auto-20150310.0900-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 10 09:04 auto-20150310.1300-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 10 16:32 auto-20150311.0912-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 11 13:02 auto-20150311.1312-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 11 16:57 auto-20150312.1026-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 12 14:20 auto-20150312.1426-1w drwxr-xr-x@ 1 lammerj staff 264B Mar 12 16:23 auto-20150313.0900-1w LAMMERJ-M-J0EB:snapshot lammerj$ cd auto-20150306.1300-1w LAMMERJ-M-J0EB:auto-20150306.1300-1w lammerj$ ls -lh total 0 drwxr-xr-x 1 lammerj staff 1.4K Mar 12 16:23 Downloads drwxr-xr-x 1 lammerj staff 840B Mar 12 14:01 Temp LAMMERJ-M-J0EB:auto-20150306.1300-1w lammerj$ GetFileInfo Temp directory: "/Volumes/temp_afp/Temp" attributes: avbstclinmedz created: 02/17/2015 19:20:35 modified: 03/12/2015 14:01:21 LAMMERJ-M-J0EB:auto-20150306.1300-1w lammerj$ cd Temp LAMMERJ-M-J0EB:Temp lammerj$ pwd /Volumes/temp_afp/.zfs/snapshot/auto-20150306.1300-1w/Temp LAMMERJ-M-J0EB:Temp lammerj$
#8 Updated by Jordan Hubbard over 5 years ago
Yeah, I think the only likely outcome to diving deeper into this is changing it from "Cannot Reproduce" to "3rd party to resolve" since this is clearly a netatalk issue, and we are not the maintainers of netatalk (separate project, separate team). The netatalk folks, in turn, are probably likely to say that ZFS is a weird animal and they're not trying to expose all of its features, just do "basic file sharing".
The recommendation from yesterday's team meeting was to use NFS on a Mac if you wanted all of the ZFS snapshots exposed, since ZFS and NFS were more-or-less designed to work together given their common birthplace at Sun.
#9 Updated by Sean Fagan over 5 years ago
I can't even do what you described above -- each attempt to access the .zfs/snapshot directory items results in log messages along the order of
Mar 13 10:11:55 MiniNAS afpd19925: ace_count = get_nfsv4_acl(path, &aces) failed: Function not implemented
Mar 13 10:11:55 MiniNAS afpd19925: solaris_acl_rights(obj, path, st, ma, NULL) failed: Function not implemented
Attempting to cd into a snapshot directory gives this ever-so-helpful error:
sef% cd auto-20150313.0900-2w
auto-20150313.0900-2w: Is a directory.
I gotta say, that's a new one on me.