Thanks for the quick followup. I'm not in front of the machine, so I can't verify the version right now (will check when I get back), but a few questions inline:
> David Bryan wrote: > > Alright, like many others who have posted here, I > am having problems with the ACL issue working with > windows. Unfortunately, the answers I've seen here > and elsewhere don't seem to resolve the problem. It > may be that an earlier suggestion (telling zfs to > ignore the ACLs during setup back in the day) are > clobbering each other... > > > > All I want to achieve is to be able to read/write > from windows (I am using NFS to share to my other > machines -- these are existing files -- and that all > works fine) I'm not trying to do anything tricky -- > full permissions to all users, not per user or > anything like that. > > > > The general suggestion is that ACLs need to be set > on the root volume. I have a zfs pool called Storage, > inside is share (a separate zfs file system, so not > sure that any of the settings to Storage apply down > to Storage/share or not). I have tried setting the > ACLs, as shown in many places. The commands I run > are: > > > > # /usr/bin/chmod > A=owner@:rwxpdDaARWcCos:fd:allow,group@:rwxpdDaARWcCos > :fd:allow,everyone@:rwxpdDaARWcCos:fd:allow /Storage > > # /usr/bin/chmod > A=owner@:rwxpdDaARWcCos:fd:allow,group@:rwxpdDaARWcCos > :fd:allow,everyone@:rwxpdDaARWcCos:fd:allow > /Storage/share > > > > If you give everyone all the permissions as in the > last entry you > don't really need the owner@ and group@ entries. Not > that it would > cause any issues but it's not needed either. > > > and also tried: > > > > # /usr/bin/chmod > A=user:bryan:rwxpdDaARWcCos:fd:allow /Storage > > # /usr/bin/chmod > A=user:bryan:rwxpdDaARWcCos:fd:allow /Storage/share > > > > New files created anywhere in the directory end up > with no permissions: > > > > # ls -alV savedfromPS.psd > > ----------+ 1 bryan share 59292 Jul 8 > 10:28 savedfromPS.psd > > > user:bryan:rwxpdDaARWcCos:-------:allow > p:2147483648:rwxpdDaARWcCos:-------:allow > > > > Assuming by directory here you mean "share" this is > the correct behavior > with second set of ACLs (the one with only one entry > for bryan) when > creating a file over CIFS but it shouldn't happen > with the first set. Seemed to happen in both cases, but I will verify. > On a side note, on ZFS looking at the traditional > UNIX permission bits > could be misleading. Like you stated here that the > file has no > permissions while it can be seen that it has an ACL > with two entries > that gives full access to bryan and the specified > group. I do think that is part of my confusion. An open question is what will happen if I try to read that file over NFS? My understanding was the NFS ignored the ACLs, so if the unix permissions are set to ----, won't the files be unreadable via NFS? > > It also has the archive bit set, meaning if I > create the file, edit it, and try to save, I can't do > it. > > > > Not exactly sure what you mean here. > What version of Nevada are you running? > Is this over CIFS? > What exactly you mean by "can't do it"? As I said, not quite sure about the version. This was a clean install from a Live CD about a month ago. The PC side is Windows XP Pro, clean install. Sorry for being unclear, let me be a bit more precise. The problem is that when a file is created on the share, using the PC, over CIFS, the file creates fine (other than having --- for traditional Unix permissions, which perhaps is ok and just looks scary to me based on my outdated thinking), but when you save again (say for example you edit, save, edit a bit more, and save again), the second save fails with an insufficient privilege error message. Clicking on the file in Windows shows the "archive" bit has been set, and when I try to unset it from Windows (again, over CIFS), I get permission denied. Essentially, I end up with one-time write. Unclear if the archive bit is causing this behavior, or is just a coincidence (It is possible that noticing it and failing to unset it is a result of the file having been created read only, but that the archive bit is not really related to the problem of not being able to save the file the second time. My understanding of the windows use of that bit would seem to indicate it wouldn't interfere with permissions) The files showing this behavior have the permissions shown in the l -alV above (with the ACL that claims I can write it). The CIFS user is bryan. > > One possible issue here is that, way back, when > setting up the system, I followed the advice of many > online sites that for a NAS, you disable the ACLs: > > > > This ZFS settings only affect ACL inheritance and > chmod locally or over > NFS, they don't affect the inheritance when you > create a file/dir over > CIFS. > > Afshin Glad to hear this possibility is ruled out. Gives me one less tree to bark up. Again, thank you for the help so far, and sorry if my description on the Windows side is a bit unclear -- I'm a Unix guy, so not always clear on my Windows lingo. David > > > zfs set aclinherit=discard Storage > > zfs set aclinherit=discard Storage/share > > zfs set aclmode=discard Storage > > zfs set aclmode=discard Storage/share > > > > I tried changing that back: > > > > zfs set aclinherit=restricted Storage > > zfs set aclmode=groupmask Storage > > zfs set aclinherit=restricted Storage/share > > zfs set aclmode=groupmask Storage/share > > > > and re-ran the same /usr/bin/chmod commands above, > but newly created files over CIFS still have the same > empty permissions. The current zfs properties are: > > > > # zfs get all Storage/share > > NAME PROPERTY VALUE > SOURCE > type filesystem - > > Storage/share creation Mon Jun 15 > 22:38 2009 - > > Storage/share used 688G > - > vailable 2.00T - > > Storage/share referenced 688G > - > ompressratio 1.00x - > > Storage/share mounted yes > - > ota none default > > Storage/share reservation none > default > ecordsize 128K default > > Storage/share mountpoint /Storage/share > default > e/share sharenfs on > local > cksum on default > > Storage/share compression off > local > ime on default > > Storage/share devices on > default > c on default > > Storage/share setuid on > default > donly off default > > Storage/share zoned off > default > apdir hidden default > > Storage/share aclmode groupmask > local > re aclinherit restricted > local > are canmount on > default > reiscsi off default > > Storage/share xattr on > default > ies 1 default > > Storage/share version 3 > - > only off - > > Storage/share normalization none > - > asesensitivity mixed - > > Storage/share vscan off > default > mand on local > > Storage/share sharesmb name=share > local > are refquota none > default > efreservation none default > > Storage/share primarycache all > default > condarycache all default > > Storage/share usedbysnapshots 0 > - > bydataset 688G - > > Storage/share usedbychildren 0 > - > byrefreservation 0 - > > > > I know I am treading on frequently covered ground, > but the "run the chmod" instructions that are given > as an answer everywhere simply don't seem to work for > me. What am I missing here? Am I seeing a legacy > problem from having the ACLs disabled at some point? > Am I improperly mounting the volume from the windows > side? > > > > Any suggestions appreciated...this is getting > frustrating! Thanks very much. > > > > Thanks, > > > > David > _______________________________________________ > cifs-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/cifs-disc > uss -- This message posted from opensolaris.org _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
