Windows 7 client saving to Mavericks share with no group permissions

Please post the ACL that was attempted, and also please confirm that ACLs are enabled on SMB.

Launch Terminal.app from Applications > Utilities and then use the command:

ls -aled@ /path/to/share

That is a directory listing (folder listing) command, with the switches a, l (ell), e, d and @. The a shows all files, the l (lowercase ell) is a detailed listing for the target file, e and @ shows ACLs and attributes, and the d indicates the target for the listing is the directory file itself and not the contents of the specified directory. Case and spaces matter here, so enter the command as shown, replacing /path/to/share with the path to the folder you're sharing.

If you're not sure of the path to the share, then enter just a # character at the prompt in Terminal.app (the comment character) and do not press return after entering that, then switch to and navigate to the folder containing the share directory using Finder, and then drag the share folder right into the Terminal.app window. The drag will leave the path in the Terminal.app display. The # is a bit of safety here, and means nothing happens if you happen to invoke the path as a command. So you can press return on

# /dragged/path/to/share

...and nothing will be invoked or happen or change, or you can use the keyboard arrow keys to remove the # and replace it with the ls -aled@ command and switches shown above, and invoke the command.

One more detail... if you have a file in that directory written by the Windows user with the following command (all one line, no wrap!):

ls -ale@ /path/to/share/pick-a-filename-from-user-windows-that-nobody-else-can-read-here

you might need to use the following to override access and view the file (again, all one line, no wrap):

sudo ls -ale@ /path/to/share/pick-a-filename-from-user-windows-that-nobody-else-can-read-here

I don't see anything in the directory ACL shown that would allow other users read or write access the file, which is likely the root issue here. You'll probably see that when you look at the above settings from the individual (and inaccessible) files — there'll be no way for other users to access the files.

Off the top, here's an example ACL that'd allow such access by any member of the staff group (this wrapped for width):

group:staff allow readattr,readextattr,readsecurity,list,search,

read,execute,writeattr,writeextattr,delete,delete_child,

add_file,add_subdirectory,write,append,file_inherit,directory_inherit

Note that allows read, write and execute access to the files, and has the inheritence settings.

Related discussions at StackExchange (and a few previous postings around the forums including here, here, here and here), and the "ACL manipulation options" section of the chmod man page documentation:

man chmod

This chmod documentation will give you a (terse) overview of what each of those keywords in the ACL means.

I don't see any particular documentation on this topic in the command line administrative manuals from Apple, unfortunately. (The somewhat-related shell-scripting primer is pretty good for learning the related topic of shell scripting, though.)

As one general approach, I'll use the Get Info (⌘I) path to create what OS X likes for its ACL settings for the target ACE, then may then manually propagate those settings to other folders and files using ls and chmod commands. This gets OS X to display the ACEs as it expects, but I find replicating those settings easier with chmod. You could well replicate the settings with Get Info, if you prefer the GUI. That also works fine.

stash.j wrote:

I've modified the group ACL for the directory so it's now showing as this;

4: group:fileaccess inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,re adextattr,writeextattr,readsecurity,file_inherit,directory_inherit

There's no read or write access granted there.

When I ls -lrt this file is showing as -rw-------+ with owner windows and group fileaccess

Still confused I'm afraid.

Which means only the owner of that object has (only) read and write access, plus whatever the ACL grants.

stash.j wrote:

Dear Mr Hoffman, I thank you for all your help here and apologise for not having replied to you sooner.

I'm sorry to say that the confusion with ACLs got the better of me, I was convinced what I wanted to see was not -rw-------+ for the permissions for files written by windows but -rw-r--r--+ so that other users could also read the file. Through all my trying (and the trying of others) I couldn't get these permissions to change but I don't think that the ACLs tie in to these permission as such but sit on top of them. Either way I'm afraid I banged my head against the wall and ended up going with an old school bodge to get the result I needed. I think you may hold your head in your hands at what I ended up doing but I has at least got me the result I wanted.

That's owner read and write, with group and other (world) with read access, and an access control list [+] with additional access controls. The contents of that access control list are evaluated in order, and are applied before the file protection mask is considered, and the contents of the list modify the access available and either allow or deny access for specific users and specific groups. After all of the access control list is considered and in the absence of a match within the access control list, then the file's own mask is considered.

Probably time for me to either look for an ACL editor that demonstrates this stuff for folks, or write one — for whatever reason, more than a few folks get this far with access controls and get quite confused. There are very brief overviews here and here, if those might help.

To solve the problem I stopped using SMB to connect Windows to the Mac server and set up an FTP location that was the root of the network share in question and granted the windows user FTP access. Files written this way reflect the permission of files written by the Mac clients.

Ah, ftp. My favorite train-wreck of a protocol, and one of the best available sources for uncontrolled leakage of login access credentials and network support hassles when there are firewalls around.