No matter which permissions I set for a file on the server, the Mac ignores them and changes the permissions back to 766. This was all on the FreeNAS SMB share.I'm having some serious permission issues with Mac client machines (OS X Snow Leopard) connected to a UNIX server (running CentOS) through Samba. rwx- 1 stux staff 15 28 Sep 18:32 u_cant_touch_this/.namedfork/rsrcġ5 bytes of resource fork data, which is actually stored in appledouble behind the scenes. $ ls -l u_cant_touch_this/.namedfork/rsrc $ echo 'resource fork!' > u_cant_touch_this/.namedfork/rsrc įor bonus points, here's a nasty way to write some data to the resource fork: u_cant_touch_thisĭrwxrwxrwx 1 stux staff 16384 28 Sep 18:23. rw-r-r- 1 stux staff 0 28 Sep 18:24 u_cant_touch_this _u_cant_touch_this: Permission deniedĭrwxrwxrwx 1 stux staff 16384 28 Sep 18:24. You can test the failure mode quite easily form OSX's terminal Which means files which look like AppleDouble can't be created/manipulated on the share. So, at the end of the day, I think its better to have transparent resource fork handling, at the expense of vetoing appledouble. Ideally, vfs_fruit would be able to use the extended attributes. It'd see the apple double files, delete them, then wonder where the resource forks went. Using a mac based resource fork safe cloner on this would be a bad idea. The problem is that file utilities, especially rsync type utils, will see them. But it will be another detritus strewn about a share by mac clients (actually by vfs_fruit). They are dot prefixed, so windows users shouldn't see them if you have 'Show Hidden Files' unchecked, and neither will Mac or Unix users (unless they look) because they're dot prefixed. The apple doubles are consumed, deleted, and appied to the expanded items. This is great, but unfortunately, means when you expand the zip, it disallows the creation of the AppleDouble directories, and then the zip expansion fails.įruit will no longer veto the appledouble files, and zip expansion works as expected. The problem is that by default vfs_fruit vetoes the appledouble files. the same ones that just got consumed, but now in the parent directory. Then vfs_fruit stores the extended attributes. OSX expands this in place, then consumes the _MACOSX directory, and sets the resource forks extended attributes on the files. The basic issue is that an OSX zip includes a _MACOSX directory, which incudes AppleDouble encoded resource forks for the various files in the zip. So I worked out how to fix the OSX can't unzip zips on a samba share error.

Samba mac os x