ewhac
Contributor
- Joined
- Aug 20, 2013
- Messages
- 177
I thought I had CIFS permissions licked and, so long as the CIFS share was simply treated like a place to dump archival files, it worked fine. But then I tried treating it like a directory to actually work in, and things went sideways. Over the weekend, I've learned a fair bit more about ACLs, and how Samba maps ZFS native ACLs to CIFS ACLs, and how merely creating a directory owned by you and with 0755 mode bits is not entirely sufficient to make Windows happy if you want to do anything more than copy whole files in and out.
The problem I'm having, basically stated, is that the Win7 client reports directories created on the share as having read-only attributes. Yet the ACLs show I have "full control" over the share, and directories created on that share.
Following guides posted here, I created a new dataset and share (labrat) for the express purpose of conducting experiments. The image below shows the general permissions of the share; the Read-Only attribute is clear:
The advanced security settings for the share further supports this, showing my user as having full control:
Next, from the Win7 client, I created a new folder within the labrat share, and looked at its properties. Somehow it has acquired a shaded Read-Only attribute:
However, inspecting the advanced security settings for the folder reveals:
Once again, my user has full control. Even when we edit the permissions, we see:
All the permissions are enabled and inherited from the parent folder (the share itself). Yet the shaded Read-Only checkbox persists. This appears to be enough to cause certain Windows applications to complain that they can't write/modify files on the share (Visual Studio 2017, to be precise).
Anyone have any clues?
The problem I'm having, basically stated, is that the Win7 client reports directories created on the share as having read-only attributes. Yet the ACLs show I have "full control" over the share, and directories created on that share.
Following guides posted here, I created a new dataset and share (labrat) for the express purpose of conducting experiments. The image below shows the general permissions of the share; the Read-Only attribute is clear:
The advanced security settings for the share further supports this, showing my user as having full control:
Next, from the Win7 client, I created a new folder within the labrat share, and looked at its properties. Somehow it has acquired a shaded Read-Only attribute:
However, inspecting the advanced security settings for the folder reveals:
Once again, my user has full control. Even when we edit the permissions, we see:
All the permissions are enabled and inherited from the parent folder (the share itself). Yet the shaded Read-Only checkbox persists. This appears to be enough to cause certain Windows applications to complain that they can't write/modify files on the share (Visual Studio 2017, to be precise).
Anyone have any clues?