X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; q=dns; s=default; b=P5H keXBmjnS/t9Mw9IT4O/e0y3yZkKe+oEOhBFtJ7+LSdJOhOvph20RcLahdnZKPp9I ws/QcZwCBcV3KIMZeAw3KZuBTL6pm2j7fdT3ltkW8AFR+Ox5lTazV0A/rJT1mVqQ WP0EudgUq/e6v1kOhH6SBFki7esKKecQQp4rkqA0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; s=default; bh=EV7OvLM4D XbFFy5aqrNwCRm9eeM=; b=czjT/2pVEGmVEA/Kx6gA1bZ774J2jQKaEinmiPeRs IHdCQrXIwpPeDVm0a4Obt3HAl3bjec4jtkg9F+cleRxIXZcKlZrgh0yukaku/baY o2A7yzohtOblUruzoZZmvMQSl3RNrNMbTjd2uN+Hsi9EbGcm0Ack7wGEPfG7Vh3s bI= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=offline, lan, H*Ad:U*allen, nsswitch X-HELO: endymion.arp.harvard.edu To: cygwin list From: Norton Allen Subject: Permissions Problems Message-ID: Date: Mon, 16 May 2016 10:13:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes I have seen problems similar to those reported in "RE: Possible issue with newest version of git (v 2.8) under Cygwin", but I did not want to hijack that thread. For me, the problems have been elusive. Scripts that used to work would fail as created directories had bad permissions, but I didn't have time to sort them out. In the last week, I finally had time to read through the documentation on the ntsec page and try some tests, and of course now I'm having trouble reproducing the problems. You'd think that was a good thing, right? I had been using /etc/passwd from mkpasswd, and based on recommendations here, I modified nsswitch for passwd: db. This seemed to work fine, and I decided I was all set. Then Windows update rebooted over the weekend, and nothing worked, and returning to 'files' resolved the problem. The exacerbating factor here is that I have a laptop connected to my work domain, but we use cached windows credentials when we are not on the work LAN (like at home over the weekend). In this scenario, cygwin was apparently unable to determine my username, and hence was unable to locate my home directory. The username is apparently cached successfully if I reboot at work and then go offline, but not if I reboot offline. Does this mean I need to stay with 'passwd: files db' for the foreseeable future, or is it possible to find the username in this scenario? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple