From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30635 invoked by alias); 2 Oct 2016 23:58:37 -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 30627 invoked by uid 89); 2 Oct 2016 23:58:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=ordinary, H*i:sk:57F19BA, H*f:sk:57F19BA, H*MI:sk:57F19BA X-HELO: mail-pf0-f182.google.com Received: from mail-pf0-f182.google.com (HELO mail-pf0-f182.google.com) (209.85.192.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Oct 2016 23:58:35 +0000 Received: by mail-pf0-f182.google.com with SMTP id e6so1758149pfk.1 for ; Sun, 02 Oct 2016 16:58:35 -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=bYdvXE/3W8qyo0XiQHkllR9UdqwVDxalFZO/C5hHrzE=; b=gTo6VAWKtOzaCV3INMj/VMwV5ufVorTV1idMK/16f7fucta4vQAbuKCe7JfrOufBTc wWGTyh4GvKVbSqjymYCiMipdio8POeJ0/+E5z/PAeqOudURU/X8Fxtqxqbf7TF97Vk4I UGEl79v0iKPvCDdmTplfeTXIHf7jGZNKDDBAfHYJpVvflHG6EuBvjGK6jUe+WD2zrEiw C9ejQ3W7OMWnOj/As8yW2U05f8vFZa9NFE6R7SeOdOAu0lhHPEPvWjZ0D+BzPFn1AKPO 4eRlOtz5l+K9fD5XRwQezphW0lIy/j7or+mi1cjvnp+cPVMXa4K/7gHXmGmpz62MBKkM +kXA== X-Gm-Message-State: AA6/9RmIeqrm95GgSOPAWyP8AlvodOuUjGAO3AFsU4boY/LQP9FexJa5bXJn1Q8PHKUoDA== X-Received: by 10.98.151.17 with SMTP id n17mr32945297pfe.73.1475452713682; Sun, 02 Oct 2016 16:58:33 -0700 (PDT) Received: from Chronos (ip68-107-32-241.sd.sd.cox.net. [68.107.32.241]) by smtp.gmail.com with ESMTPSA id t5sm2461321pfi.78.2016.10.02.16.58.32 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 02 Oct 2016 16:58:33 -0700 (PDT) Date: Mon, 03 Oct 2016 01:28:00 -0000 From: Wayne Porter To: cygwin@cygwin.com Subject: Re: Unknown+User Unix_Group+505 on smb shares in a domian Message-ID: <20161002235831.d6mvng5elrfs66is@Chronos> References: <57EB4449.7010206@tlinx.org> <20160928180456.GA1128@hdmetxxxx33004g.AD.UCSD.EDU> <57ECA908.9010402@tlinx.org> <20160929184039.GD12532@hdmetxxxx33004g.AD.UCSD.EDU> <57F19BAE.4070004@tlinx.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kmoa5r4uitibp7hh" Content-Disposition: inline In-Reply-To: <57F19BAE.4070004@tlinx.org> User-Agent: NeoMutt/20160910 (1.7.0) X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00032.txt.bz2 --kmoa5r4uitibp7hh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4161 On Sun, Oct 02, 2016 at 04:43:42PM -0700, Linda Walsh wrote: > Wayne Porter wrote: > > > Essentially you have a bunch of users on different machines that are= n'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 = windows > > > domain) and moving the user accounts into the domain. Each local acc= ount > > > 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, corresp= onding > > > 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. It just happens that Cygwin, which I'm = the only > > one using, maps the Windows mapped drives to an unknown user account an= d makes > > using it difficult. > --- > Working in windows where? What does "working just fine in Windows" mean? > That people in explorer on your machine have read+write access to the lin= ux-shares? >=20 > Or do you have domain access to the machines running Windows? > Are those machine in your Domain or are they outside your domain like the= linux > machines? >=20 If I open the W:\ drive in Windows, I have full read/write access. This is established via NET USE commands at boot. Then when I open Cygwin and navigate to the same location, which has been mapped by Cygwin to /cygdrive/w/ the user permissions appear as in my first email. Even though it says I have read-only access, I have full read/write ability. >=20 > >=20 > > > This is an organizational problem that has nothing to do with > > > cygwin, but whether windows and linux machines are using domain or ma= chine-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 = the > > > 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. > --- > If you have write access, then you are saying the permission are not dis= playing > properly in Cygwin. So do you have the same, *actual* access in Cygwin as > windows (ignoring what permissions may be displayed)? It could be that y= ou > have domain-admin > access and are overriding listed permissions on remote machines. If it's= the case > that your user doesn't have R+W access, but you are a domain admin, you m= ight just > be overriding the write-restrictions in windows as well as cygwin. >=20 Yes, I have the same permissions, Cygwin is just displaying the wrong thing. >=20 >=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. > --- > Bingo! You need to try something like > "runas [alternate credentials + alternate password] net use W: ..." >=20 > That might work... but is really icky, since you can't easily automate th= at > without storing the password in clear-text in some file in your profile..= . that's > not a good solution. >=20 There are many things currently wrong with our setup and passwords in clear-text wouldn't be anything out of the ordinary, I'm afraid. The script that maps these shares with NET USE already have them in it and load on boot, so I just need to adjust them to use "runas" instead of the current way, which is just to specify the username and password in the command? If you look at the info I provided in my first message, the NET USE script I use is there, with the username and passwords redacted. --kmoa5r4uitibp7hh Content-Type: application/pgp-signature; name="signature.asc" Content-length: 473 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJX8Z8mAAoJEMcDZgYHTWDO/3AH/R5n4ZYuMkAKVmJ/uvWGVWKd RGqSMgoVhwfen4gUFuq20z3lus89SPuyqxKWjcelIKEVG5MVEn8liOVX7ZU6DoJF y+9HsZS/Rs6tNJYIFYT5nu1TPGhFI5iCg0GEIzwC16G6ZVBx3Pj9uoilo2ilzYTz A4NM5GvBTc+Te7NUoy/KnLlaAIMjo+3bVn+xv2ZmCi/w1ra6lG8VVovGbWh4K4re 6sKksOmBaR806x+oXPZU0qqLBrygw6iN4qygbdFsOmrQ8RJKTp47JDVG5EA6W/7K m1I7MSBC8ya71t89ZEOqcE0ymHWcfIhUy4sradn6HedzxaxP5+hYSSy5xtZx0HY= =vGrT -----END PGP SIGNATURE----- --kmoa5r4uitibp7hh--