1

on my linux server, I have mounted my zfs pool here: ~/data/homepool and ~/data is shared via afp. My macOS (high sierra) client can correctly see and read/write ~/data and in fact even write in data/homepool.

The problem is that macOS Finder gets the wrong storage capacity of homepool, Finder indicates the storage space of homepool as the storage space of ~/data, while as homepool is mounting a zfs pool, homepool is very large. This is preventing Finder to copy large files and Finder thinks there is no available space. Is it a bug..?

Tiutto
  • 179
  • 1
  • 12

2 Answers2

0

However, if you share directly ~/data/homepool (instead of ~/data) over AFP the MacOS client gets the correct space size, so this is the workaround.

Tiutto
  • 179
  • 1
  • 12
0

Yes, this seems like a bug in AFP. Based on what you're saying, it seems like they aren't looking for additional capacity in filesystems mounted below the shared folder.

In addition to the workaround you cited (share the ZFS filesystem instead of the directory containing the ZFS filesystem), you could also use cp / rsync / dd / some other command line utility to copy files into the share, since I don't think those typically check for space before copying.

In theory, I see how they could do this differently -- I think it would require checking all the mounted filesystems, querying the space available in each of them and then adding that to the space available in the directory that they're all mounted into. However, given that some of those filesystems mounted into this directory could also be network shares (AFP / NFS / etc.), this could be a disaster for performance of the "how much space is available" query.

Dan
  • 7,155
  • 2
  • 29
  • 54