similar to: getent not displaying builtin groups or users

hi everyone > Yes, but you can add these two lines to smb.conf: > > winbind enum users = yes > winbind enum groups = yes > > This will allow getent to list all users and groups, but is not > recommended if you have a lot of users. > > Rowland thanks the dc's now lists all the domain users and groups. the domain users gid is correct on both dc's the uid

hi everyone i'm having trouble figuring out why i'm getting NT_STATUS_NO_LOGON_SERVERS errors, i have two samba ad domain controllers running on raspberry pi's i think it a recent problem since an upgrade because i was able to list domain users on a joined member server but now getent only lists local users, i've read that the problem might be due to avahi which i stop with

Hi everyone my sssd log shows the nsupdate command failing, how do i test ddns separately from sssd to see if the problem is in sssd or samba. shadrock /etc/sssd/sssd.conf ------------------------------------------------- (Fri Aug 1 12:18:30 2014) [sssd[be[tissisat.co.uk]]] [be_nsupdate_timer_schedule] (0x0200): Timer already scheduled (Fri Aug 1 12:18:30 2014) [sssd[be[tissisat.co.uk]]]

hi Roland > On Tue, 1 Nov 2016 11:00:15 +0000 > niya levi via samba <samba at lists.samba.org> wrote: > >> hi everyone >> >> i have configured 2 domain controllers and a domain member >> >> the domain member is joined to the domain and >> >> ad and rfc2307 is configured for idmap backend, >> >> wbinfo returns domain builtins for

Hi all *Context:* I'm trying to use the s4bind scripts ( http://linuxcostablanca.blogspot.com.es/p/s4bind.html) k5start is running So far, i've succeeded in * modifying (posixifying) the built-in "Domain Users" * adding a user to this group and i can login with this user (ssh), create files that are correctly owned, etc... The user also shows up correcly in ADUC. * retrieving

> >/$ sudo getfacl /smb/Printer_drivers/ />/getfacl: Removing leading '/' from absolute path names />/# file: smb/Printer_drivers/ />/# owner: root />/# group: domain\040admins />/# flags: -s- />/user::rwx />/group::rwx />/other::r-x />/default:user::rwx />/default:group::rwx />/default:group:domain\040admins:rwx />/default:mask::rwx

> On Mon, 21 Nov 2016 13:42:57 +0100 > "L.P.H. van Belle via samba" <samba at lists.samba.org> wrote: > >> Hi, >> >> Yes thats correct. >> But try the following. >> Make sure you use the usermapping. >> >> username map = /etc/samba/samba_usermapping >> containing: >> !root = NTDOM\Administrator NTDOM\administrator

There should be no functional changes here Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Juston Li <juston.li at intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 71 ++++++++++++++++----------- 1 file changed, 42 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 9b1b5c9b1fa0..2ab16c9e6243

When reprobing an MST topology during resume, we have to account for the fact that while we were suspended it's possible that mstbs may have been removed from any ports in the topology. Since iterating downwards in the topology requires that we hold &mgr->lock, destroying MSTBs from this context would result in attempting to lock &mgr->lock a second time and deadlocking. So, fix

On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote: > There should be no functional changes here Would be good to explain what you did refactor here, instead of me trying to reconstruct it from the patch. Especially pre-coffee that helps :-) > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- >

When reprobing an MST topology during resume, we have to account for the fact that while we were suspended it's possible that mstbs may have been removed from any ports in the topology. Since iterating downwards in the topology requires that we hold &mgr->lock, destroying MSTBs from this context would result in attempting to lock &mgr->lock a second time and deadlocking. So, fix

On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote: > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > > When reprobing an MST topology during resume, we have to account for the > > fact that while we were suspended it's possible that mstbs may have been > > removed from any ports in the topology. Since iterating downwards in the > > topology requires

s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming scheme, and will make even more sense once we redesign how the current refcounting scheme here works.

On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote: > On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote: > > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > > > When reprobing an MST topology during resume, we have to account for the > > > fact that while we were suspended it's possible that mstbs may have been > > > removed from any

Which reduces indentation and makes this function more legible. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Signed-off-by: Lyude Paul <lyude at redhat.com> ---

Once upon a time, hotplugging devices on MST branches actually worked in DRM. Now, it only works in amdgpu (likely because of how it's hotplug handlers are implemented). On both i915 and nouveau, hotplug notifications from MST branches are noticed - but trying to respond to them causes messaging timeouts and causes the whole topology state to go out of sync with reality, usually resulting in

Once upon a time, hotplugging devices on MST branches actually worked in DRM. Now, it only works in amdgpu (likely because of how it's hotplug handlers are implemented). On both i915 and nouveau, hotplug notifications from MST branches are noticed - but trying to respond to them causes messaging timeouts and causes the whole topology state to go out of sync with reality, usually resulting in

* Remove the big ugly have_eomt conditional * Store &mgr->down_rep_recv.initial_hdr in a var to make line wrapping easier * Remove duplicate memset() calls * Actually wrap lines Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Reviewed-by:

On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > When reprobing an MST topology during resume, we have to account for the > fact that while we were suspended it's possible that mstbs may have been > removed from any ports in the topology. Since iterating downwards in the > topology requires that we hold &mgr->lock, destroying MSTBs from this > context would

There's a couple of changes here, so to summarize: * Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on indenting * Store &mgr->up_req_recv.initial_hdr in a variable so we don't keep going over 80 character long lines * De-duplicate code for calling drm_dp_send_up_ack_reply() and getting the MSTB via it's GUID * Remove all of the duplicate calls to