Netatalk and Solaris CIFS are incompatible regarding permissions in an
AD environment or regarding groups.
One problem hides in the + of
-rwx------+ 1 olaf olaf 469 Aug 2 17:12 scaletta2.txt
This means that there are ACLs defined.
While netatalk uses classic Unix permissions (owner/group/everyone),
Solaris CIFS works like Windows what means: It uses ACL only, uses
Windows SID in AD environments and Windows SMB groups instead of Unix
groups.
The group:2147483648 is an SMB group that is unknown to netatalk while
the group olaf is a Unix group that is unknown to Solaris CIFS.
Your options are:
1.
Avoid netatalk as it is dead and always a source of problemws. Apple
switched to SMB so this is the future. (This is what I did). Currently
you have the Problem that Illumos lacks SMB2 and OSX is slow with SMB1.
Hope that this will come in the near future to OmniOS as it is in
NexentaStor and Solaris 11.3.
First tests on Solaris show that smb is there as fast as AFP.
2.
Avoid AD, groups and set permissions on Windows only for users or use
id mapping
This is a workaround
3.
Use SAMBA as it rely on Unix permissions as well
(For what I use SMB, Solaris CIFS is superieur, so an option that I
would avoid)
my tip is 1.
Gea
Am 02.08.2015 17:39, schrieb Olaf Marzocchi:
Hello,
in my server (latest stable release) I use netatalk to share files
with OS X and I use CIFS (kernel) for Windows.
I never noticed until now that the files made by the two operating
systems have mismatching and incompatible permissions. This prevents
me from modifying or deleting under an operating system the files
created with the other one.
For example:
-rw-r--r-- 1 olaf olaf 469 Aug 2 17:12 scaletta.txt
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
-rwx------+ 1 olaf olaf 469 Aug 2 17:12 scaletta2.txt
user:olaf:rwxpdDaARWcCos:-------:allow
group:2147483648:rwxpdDaARWcCos:-------:allow
The first one was generated by netatalk and correctly shows the
permissions according to the user/group I used to login, it also
inherited extended ACL according to the parent folder.
The second file was created by Windows 8.1, when connected to my
server using SERVER@username as login (to be sure I am logging in with
a user local to the server), and added strange ACL:
user:olaf/group:2147483648
The server is not connected to any AD and I am using a normal
workgroup setup.
Where can I find some info to understand the issue? is there something
obvious I missed? in my configuration?
Thanks!
Olaf Marzocchi
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
