Ah ha. Right you are. Groups now list all the members, but, it seems all the
group members are listed as "John Doe" rather than jdoe which means that when
jdoe logs in, he can't access his groups due to the naming disconnect. Any
ideas of how to fix that? Somehow map the group members to samAcco
On Thu, Apr 21, 2016 at 06:39:08PM -0700, Michael Talbott wrote:
> -a attributeMap=group:uniqueMember=member \
Pretty sure this should be "group:memberUid=member"...
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.c
On Thu, Apr 21, 2016 at 9:53 PM, Gordon Ross wrote:
> I'm not sure how anyone ever gets access when your ACL has this ACE:
> everyone@:rwxpdDaARWcCos:fd-:deny
>
> Every long has the group ...
Hah! Spell checkers - Gr! That should have read:
Every logon has the group...
_
I'm not sure how anyone ever gets access when your ACL has this ACE:
everyone@:rwxpdDaARWcCos:fd-:deny
Every long has the group "everyone" as a member, therefore that ACE
will match every logon. The ace also lists every possible permission,
so nothing should get through, no matter wha
Sorry for the duplicate thread. My email client died when I hit send and I
thought it didn't go the first time, but I guess it did :(
> On Apr 21, 2016, at 6:39 PM, Michael Talbott wrote:
>
> I've been trying to figure out where I'm going wrong and just can't seem to
> pinpoint the problem. I
I've been trying to figure out where I'm going wrong and just can't seem to
pinpoint the problem. I'm trying to move a few servers away from winbind which
was using rfc2307 mappings for uid/gid mapping and use LDAP instead. Using the
below configuration username/userid groupname/groupid match th
It's not critical for people who don't use the GSSAPI *Key exchange*.
You're good.
Dan
Sent from my iPhone (typos, autocorrect, and all)
> On Apr 21, 2016, at 5:50 PM, Michael Rasmussen wrote:
>
> On Thu, 21 Apr 2016 17:17:32 -0400
> Dan McDonald wrote:
>
>>
>> have the details. A custome
Hi Dan,
The following error prevents the wiki to function under webkit based
browsers:
Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart' was
loaded over a secure connection, but contains a form which targets an insecure
endpoint 'http://omnios.omniti.com/post-attachment.
On Thu, 21 Apr 2016 17:17:32 -0400
Dan McDonald wrote:
>
> have the details. A customer-critical ZFS bugfix suite (illumos 6841-6843)
> and some HW bumps highlight this update.
>
> It's a rebuild of illumos-omnios, so a reboot will be necessary. Release
> media (USB-DD, ISO, Kayak) has been
The Long-Term Stable release (r151014) has received an update. The release
notes for r151014:
http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014
have the details. A customer-critical ZFS bugfix suite (illumos 6841-6843) and
some HW bumps highlight this update.
It's a rebuild of i
> On Apr 21, 2016, at 3:21 PM, Steven Ford wrote:
>
> Dan, since you made these commits, do you have any thoughts? Could these be
> related?
>
Those are both kernel panic fixers (improper release after failure).
The non-global-zone SMB/CIFS fixes went into r151016, along with other fixes.
Hi Olaf
On Thu, Apr 21, 2016 at 8:31 PM, Olaf Marzocchi wrote:
> Thanks for the help.
> Well first of all, how can the SMB server require everyone to have
> read/execute access? no more private shares?
>
> Anyway, I got it working (for now) with:
>
> drwxr-xr-x+ 16 olaf olaf 16 Apr
Olaf,
The large number of changes between the version of OpenIndiana I was
running and r151016 made it daunting to pinpoint the problem. If this is
the same problem, I think it's safe to say the change was between r151014
and r151016. I'm not very savvy with the source code but I'll take a look.
Between r151014 and r151016, the only commits that look relevant to me are:
https://github.com/omniti-labs/illumos-omnios/commit/8f5190a540d64d2debee6664bbc740e4c38f5b7f
https://github.com/omniti-labs/illumos-omnios/commit/0f92170f1ec2737ee5a0e51b5f74093904811452
However, I am not familiar with t
Thanks for the help.
Well first of all, how can the SMB server require everyone to have
read/execute access? no more private shares?
Anyway, I got it working (for now) with:
drwxr-xr-x+ 16 olaf olaf 16 Apr 21 20:25 olaf
user:olaf:rwxpdDaARWcCos:fd-:allow
g
Yes I saw it but it was about guest access, while my case is about a
share restricted only to its owner because I wanted to be sure that
private data stay private:
OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
total 34
drwx--+ 15 olaf olaf 15 Oct 25 11:27 olaf
user:olaf:
> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann wrote:
>
> [About ZFS scrub tunables:]
>> Interesting read - and it surely works. If you set the tunable before
>> you start the scrub you can immediately see the thoughput being much
>> higher than with the standard setting. [...]
>
> It's perhap
[About ZFS scrub tunables:]
> Interesting read - and it surely works. If you set the tunable before
> you start the scrub you can immediately see the thoughput being much
> higher than with the standard setting. [...]
It's perhaps worth noting here that the scrub rate shown in 'zpool
status' is a
Am 19.04.16 um 23:31 schrieb wuffers:
You might want to check this old thread:
http://lists.omniti.com/pipermail/omnios-discuss/2014-July/002927.html
Richard Elling had some interesting insights on how the scrub works:
"So I think the pool is not scheduling scrub I/Os very well. You can
incre
19 matches
Mail list logo
