Right, no dedup, no cifs folding. The df man page on the filer states "Unit values are based on powers of two. For example, one megabyte is equal to 1,048,576 bytes." So it looks like it's not GB vs GiB.
On the netapp with df I get 290673272KiB or 297649430528 bytes.
Windows Explorer (using the technique I mentioned earlier) displays 314462265344 bytes or 292GiB. Mapping that share to a drive and checking the drive properties reports values inline with the output of df on the filer: 277 GiB used.
Mounting the share via cifs from a linux box and running df produces output identical to the output of the df command on the filer. What's interesting is that if I run du -hs at the root of the mounted volume I get back 275G. The man page for du states that it "estimates" file space disk usage so I'm assuming that accounts for the 2G discrepancy there. Running du -hs --apparent-size instead returns 293G which is inline with what windows reports 314462265344 bytes = 292.86580658GiB. The man page for du says about the apparent size flag:
print apparent sizes, rather than disk usage; although the apparent size is usually smaller,
it may be larger due to holes in (‘sparse’) files, internal fragmentation, indirect blocks,
and the like
So I guess selecting all the files and folders in the share, right clicking, and doing a properties in windows is roughly analgous to du -s --apparent-size and the discrepancy I'm seeing is caused by "holes in (‘sparse’) files, internal fragmentation, indirect blocks, and the like"