From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106118 invoked by alias); 1 Oct 2016 22:13:16 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 106109 invoked by uid 89); 1 Oct 2016 22:13:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=dreams, HX-Received:10.66.185.133, slightest, accounts X-HELO: mail-pa0-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Oct 2016 22:12:52 +0000 Received: by mail-pa0-f47.google.com with SMTP id oz2so49202891pac.2 for ; Sat, 01 Oct 2016 15:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UuOYiPTC9HvyDxIMQElM0kddq+BpKLPsr6zC6SEMNcY=; b=Xuv8ANUGW392zOCXyh0siSGksQGQqEgqTIy7PenEgMU8bf4itS8uUxLsevJUbuarVC uaJ6EEvbHCPO8Hph7ut7muVNyflpwdWuc4UUSew4TKa9BarN7umgn7SPvKBmA1+0sCjS KxmrNK2Mppy7IBKCHXbr4ovpdkDWv8TUzFTT1LklAcTYxfqoWlN+4fTvAXoMto+9IMGY sm3ypeuVmAJKdK5A9Vk9qJ+EYnGbklaIypl4cDXZZC6Hkh4AXAgk2RyqdhlKJCBViLZH BMzAXLfD9sN4aAA6Vb2jAhROd/Ng9u1gP9L9C9m7SqltFpmO5EHVrMqdH2qDww+NVdOq VR6w== X-Gm-Message-State: AA6/9RlPMAWX8lE3IY6bYcEjjneuamXe9Ew3BiZH3bsd/Jo9apqNAJY3rdW9w5hjlnQjPQ== X-Received: by 10.66.185.133 with SMTP id fc5mr24231924pac.71.1475359970515; Sat, 01 Oct 2016 15:12:50 -0700 (PDT) Received: from Chronos (ip68-107-32-241.sd.sd.cox.net. [68.107.32.241]) by smtp.gmail.com with ESMTPSA id xv9sm37032729pab.36.2016.10.01.15.12.49 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 01 Oct 2016 15:12:49 -0700 (PDT) Date: Sat, 01 Oct 2016 22:38:00 -0000 From: Wayne Porter To: cygwin@cygwin.com Subject: Re: Unknown+User Unix_Group+505 on smb shares in a domian Message-ID: <20161001220016.jqng3cphusknegqn@Chronos> References: <57EB4449.7010206@tlinx.org> <20160928180456.GA1128@hdmetxxxx33004g.AD.UCSD.EDU> <57ECA908.9010402@tlinx.org> <20160929184039.GD12532@hdmetxxxx33004g.AD.UCSD.EDU> <1614136129.20160929233414@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tujs7kklqcp7wvaj" Content-Disposition: inline In-Reply-To: <1614136129.20160929233414@yandex.ru> User-Agent: NeoMutt/20160910 (1.7.0) X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00010.txt.bz2 --tujs7kklqcp7wvaj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3390 On Thu, Sep 29, 2016 at 11:34:14PM +0300, Andrey Repin wrote: > Greetings, Wayne Porter! >=20 > >> Essentially you have a bunch of users on different machines that= aren't > >> sharing their files under any common (or shared) security authority > >> (like a single domain). Until you persuade the owners of those linux = machines > >> to move the linux machines under a common security authority (like a w= indows > >> domain) and moving the user accounts into the domain. Each local acco= unt > >> would have to be moved to a domain account with the files under each > >> machine-local account being moved (or "chown'ed") to the new, correspo= nding > >> domain account). >=20 > > The shares are mapped and working just fine in Windows. To IT, there is= n't > > anything that needs to be done. >=20 > If they really believe that, they are even less qualified than I've thoug= ht. > The whole thing works by a pure accident. And a slightest change in > conventions or default behavior of either Windows or Samba may bring the = end > to the happy dreams of your IT dep. >=20 > > It just happens that Cygwin, which I'm the only one using, maps the Win= dows > > mapped drives to an unknown user account and makes using it difficult. >=20 > Windows maps it to an unknown user account also. > It just happens to know, from which server the account came and can fetch= the > names in a subrequest. But they are NOT domain names, neither their UID's= are > domain UID's. You can't even control permissions from domain, you'd need = to > login to the machine and fiddle with perms locally. >=20 > >> This is an organizational problem that has nothing to do with > >> cygwin, but whether windows and linux machines are using domain or mac= hine-local > >> security. Until your linux machines and their local user become part = of the > >> domain, you can't expect any "write" privileges granted to you under t= he > >> domain to work on the linux machines. > >>=20 >=20 > > I have write permissions on those machines from Windows. Cygwin thinks = I don't so > > files are opened in read-only mode but when I force them to be written,= it works. > > I'm not sure if maybe I left this out of my initial information, but th= ese are > > shares that are mapped in Windows on login and there are no issues ther= e, but once > > I open Cygwin, I don't appear to have write access even though I do. >=20 > > When mapping the drives in Windows, a username and password are given. = Is there no > > way to let Cygwin know about that username without joining the servers = to the domain? > > I know that this setup isn't ideal, which is why I'm trying to find a w= ork-around. >=20 > I've had this same setup for years, and one unlucky friday, it blew in my= face > when I was committing an important batch of change in my project to the > repository. > I've spent next two weeks salvaging the working copy. But nothing worked = until > I said "fuck it" and finally took my time to reinstall 64-bit OS and setu= p a > domain (this is my home network, so I though with only me using it there'= s no > pressing... guess there was). >=20 >=20 My situation is not ideal and I will try to convince IT to change their ways, but there is a chance that I'll be using the current work-arounds for a while. Thanks for the advice and the warnings about what to expect in the future. Thanks, Wayne --tujs7kklqcp7wvaj Content-Type: application/pgp-signature; name="signature.asc" Content-length: 473 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJX8DTfAAoJEMcDZgYHTWDOdYkH/3XVU0uOThHxdM4Zk2La77ao 0PxdSGvjosvF6qA+mfG4ikYZRPet2LPLgNbrFNQL58eSNBpxx3k8lS2l1J/XYD2x vqzeVdZr9mr6MRnwbVHz9k5E7NaJX8al0SO5rAV4LE3JyhCWl34D8gh8OKdTD5Kv 3DjJ1qfgjT36kNIn1UUwTtnpPH58MA/BQYdlsxKimZIweGzaj5g1t1p+CRfnLVLO k0/MfMrkFVp7emNFM7+VuL89q4ZauFrfXCcWFijA2fxcffpcxYiWT8n+pcVx8Cat Zj+2DeqPw6uIrzlefJBD7c3184iLWC+f7uNROAty8I+BwCPXBKbTvfqkWA5DxbY= =DgjV -----END PGP SIGNATURE----- --tujs7kklqcp7wvaj--