AFP only works on servers/NAS devices that support it. It is Apple's proprietary network file protocol, and I believe they have abandoned it in favor of SMB2. If you use Windows-based servers or NAS devices that only support SMB- it isn't an alternative.
CIFS is an alternative that forces the use of SMB1 in Mavericks, without using the SMB1 hack (earlier in this discussion). For whatever reason- it seems to actually work worse than the old Mac SMB implementation.
iWork is still useless on network shares, and CIFS/SMB1 still randomly disconnect and cause permission corruption for all of our users who we upgraded to Mavericks. For the record- we had random and infrequent permission corruption in earlier versions of OS X, but with Mavericks- we can count on it on a regular basis.
I'll look at Tuxera, but as a rule- we try to keep things as "native" as-possible to avoid future compatibility issues. This is a problem Apple needs to get fixed if they really want to make serious inroads into the Enterprise, which they claim they do. In many ways- their competition is self-destructing and becoming desperate- they should be taking advantage of it. I had to buy six new Windows computers this month for my company, which could have been MacBooks if it wasn't for these problems.
Just as follow-up: From what I can tell from their own documentation and support database- Tuxera is strictly an NTFS stack/driver for Mac (and other non-Windows devices). It allows the reading and writing of NTFS drives. That actually has nothing to do with SMB at all. It is likely very useful to connect to USB drives running NTFS, but not actual NAS devices or servers. It's possible it may help with permission issues tied to NTFS via SMB, but there is nothing on their Web site that indicates that. I may give it a try anyway.
Also, with regard to my previous reply, I believe AFP is still used by Time Capsule, but not by most 3rd party NAS devices, which use CIFS/SMB1.
I do have a workaround - of sorts. This allows iWork '09 documents to co-exist with iWork '13 documents.
If you rename the three iWork Apps in /Applications/iWork '09 by appending (say) '09', so Numbers becomes Numbers09, you can alter the "Open with" file property (using %I) to reference the new name.
This works for files on an AFP or SMB share.
Note that "Change All".. doesn't work.
And also note that if a version of an iWork Application is already running, additional concurrent file opens will use the same version.
Haven't seen any negative consequences of this so far.
For OS X Server 10.9.1 I have resorted to running a shell script to recursively set ACL group owner and full control permissions (in my case Workgroup) every 15 minutes:
# Fix ACLs for iWork 3
echo "Fixing ACLs"
chmod -R +a "Workgroup allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,re adextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_i nherit" /path/to/your/directory
# put message in system log
syslog -s -l error "ACLs have been changed to Workgroup"
make it run as root
chmod u+s /usr/local/bin/iworkfix.sh
schedule via launchd every 15 mins, in /Library/LaunchDameons/com.example.iworkfix.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
(you can also use lingon.app to create your launchd plist)
This only works as a solution if one previously had installed iWork '09. It does nothing to fix a problem that Apple seems to be ignoring, and as others have noted- this affects far more than just iWork. There are underlying SMB permission and access issues that can negatively impact anything stored on an SMB share. The current version of iWork just becomes unusable because of it.