David Bryan wrote:
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.
Yes, please do.
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?
I'm not sure what exactly will happen over 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.
If the user over CIFS is bryan and the ACL is what you've
reported here then you shouldn't run into any issues.
Have you checked if the ACL changes after the first or the
second save? what is the application you are using? Do you
see this problem with any file type or just .psd files?
Afshin
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
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
