Cygwin protection issues accessing SAMBA shares

I’ve posted about my instance of this to the Cygwin mailing before, years ago and again just now, and read a lot of what’s online about it. I’ve also asked people over in the FreeNAS community (and gotten basicaly the same answer). Basically everything I can find says that the information is here.

What’s there doesn’t work for me. Across many Cygwin installs on multiple windows versions (at least 7 and 10) on at least 4 different hardware platforms. Including one work computer accessing a Synology server, so *completely* different software on the server side (dev network at work, no Active Directory there, so it’s just like home, local logons only).

The Samba server at home is a FreeNAS box. It’s *not* joined to any domain, nor are the windows boxes (it’s at home, I have no AD server, it’s all local logons). Currently running FreeNAS 11.1 U5, if it matters (latest), which seems to be running samba version 4.7.0-GIT-de2f31198c7-FreeNAS.

Details will be from my Windows 10 desktop, where I did a clean install of Cygwin-64 last night; it identifies itself (uname -a) as CYGWIN_NT-10.0 DDB4 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin.

This box has accessed this server (multiple FreeNAS and hence Samba servers over the years) as both Windows 7 and windows 10. It works fine in windows, I can adjust file security through the Windows explorer dialogs, etc. (My desktop computers, or my last 3 or 4 desktop coumpters really, running windows and Cygwin in some version, has accessed a file server via CIFS for most of my file access since about 2006; that fileserver has been Solaris with ZFS and then FreeNAS with ZFS. I’ve also had at least three laptops configured to use this server and having Cygwin, and they all behaved the same as the desktop at that moment. I started having protection problems when Cygwin made the changes described in the link above.)

Cygwin works fine on locally-hosted files (not that I have many; a small SSD for software installation, plus external drives I may attach from time to time, everything important lives on the fileserver). The protections Cygwin shows for files on the NAS look like what I will get if the underlying problem *is* something related to the ntsec article above. That kinda gives me hope that I’m just doing something wrong that I’m unable to spot.

On the FreeNAS box, user ddb (uid 1001) owns the files in question:

[root@fsfs /mnt/zp1/ddb/Documents/Recipes]# id ddb uid=1001(ddb) gid=1001(ddb) groups=1001(ddb),0(wheel),20(staff),1004(public),1007(music),1712(bdr)
[root@fsfs /mnt/zp1/ddb/Documents/Recipes]# ls -l S*
-rwxrwxr-x+ 1 ddb ddb 9605 May 30 2004 Sacher.asc
-rwxrwxr-x+ 1 ddb ddb 9600 May 30 2004 Sacher.doc
-rwxrwxr-x+ 1 ddb ddb 4867 May 30 2004 Salsa.asc
-rwxrwxr-x+ 1 ddb ddb 4864 May 30 2004 Salsa.doc
-rwxrwxr-x+ 1 ddb ddb 2181 May 30 2004 Shrmpstr.asc
-rwxrwxr-x+ 1 ddb ddb 2176 May 30 2004 Shrmpstr.doc
-rwxrwxr-x+ 1 ddb ddb 20841 Dec 4 2012 Spaghetti.odt

Locally, it’s mapped as Windows drive P: (at the ‘Documents’ level in the above path), but also directly accessible as //fsfs/ddb/Documents.

$ id
uid=197612(ddb) gid=545(Users) groups=545(Users),197121(None),197613(fsfsddb),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This Organization),113(Local account),66048(LOCAL),262154(NTLM Authentication),401408(Medium Mandatory Level)

$ ls -l /cygdrive/p/Recipes/S*
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 9.7k May 30 2004 /cygdrive/p/Recipes/Sacher.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 9.6k May 30 2004 /cygdrive/p/Recipes/Sacher.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 4.9k May 30 2004 /cygdrive/p/Recipes/Salsa.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 4.9k May 30 2004 /cygdrive/p/Recipes/Salsa.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 2.2k May 30 2004 /cygdrive/p/Recipes/Shrmpstr.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 2.2k May 30 2004 /cygdrive/p/Recipes/Shrmpstr.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 21k Dec 4 2012 /cygdrive/p/Recipes/Spaghetti.odt

$ ls -l //fsfs/ddb/Documents/Recipes/S*
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 9.7k May 30 2004 //fsfs/ddb/Documents/Recipes/Sacher.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 9.6k May 30 2004 //fsfs/ddb/Documents/Recipes/Sacher.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 4.9k May 30 2004 //fsfs/ddb/Documents/Recipes/Salsa.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 4.9k May 30 2004 //fsfs/ddb/Documents/Recipes/Salsa.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 2.2k May 30 2004 //fsfs/ddb/Documents/Recipes/Shrmpstr.asc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 2.2k May 30 2004 //fsfs/ddb/Documents/Recipes/Shrmpstr.doc
-rwxrwxr-x 1 Unknown+User Unix_Group+1001 21k Dec 4 2012 //fsfs/ddb/Documents/Recipes/Spaghetti.odt

That “Unknown_User” is the signature of this problem, right?

And I can create a file, and read it, but not replace it:

$ echo testing > /cygdrive/p/Recipes/test001.txt

$ ls -l /cygdrive/p/Recipes/test001.txt
----r--r-- 1 Unknown+User Unix_Group+1001 8 Jun 16 13:08 /cygdrive/p/Recipes/test001.txt

$ echo replace the file > /cygdrive/p/Recipes/test001.txt
-bash: /cygdrive/p/Recipes/test001.txt: Permission denied

(note no indication that there is an ACL; which is compatible with the following)

$ getfacl /cygdrive/p/Recipes/test001.txt
# file: /cygdrive/p/Recipes/test001.txt
# owner: Unknown+User
# group: Unix_Group+1001


My Cygwin setup doesn’t have /etc/passwd or /etc/groups

$ ls /etc/passwd
/usr/bin/ls: cannot access '/etc/passwd': No such file or directory
$ ls /etc/group
/usr/bin/ls: cannot access '/etc/group': No such file or directory
$ ls /etc/groups
/usr/bin/ls: cannot access '/etc/groups': No such file or directory

(Wasn’t absolutely sure of my memory whether group was plural or not 🙁 ; but neither one exists.)

I have configured /etc/nsswitch as I believe is directed (everything left defaults, except change db_gecos to schema “desc”):

$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
# This file is read once by the first process in a Cygwin process tree.
# To pick up changes, restart all Cygwin processes. For a description
# see
# Defaults:
# passwd: files db
# group: files db
# db_enum: cache builtin
# db_home: /home/%U
# db_shell: /bin/bash
# db_gecos: <empty>

db_gecos: desc


I have configured the user comment for me, user ddb, in SAM, via the net user command, to have the xml-like Cygwin data in the comment:

$ net user ddb
User name ddb
Full Name David Dyer-Bennet
Comment <cygwin unix="1001" group="Users" />
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never

Password last set 6/2/2017 11:17:13 PM
Password expires Never
Password changeable 6/2/2017 11:17:13 PM
Password required Yes
User may change password Yes

Workstations allowed All
Logon script
User profile
Home directory
Last logon 6/16/2018 12:26:50 PM

Logon hours allowed All

Local Group Memberships *Administrators *fsfsddb
Global Group memberships *None
The command completed successfully.

And I have also done that for the group:

$ net localgroup Users
Alias name Users
Comment <cygwin unix="1001" />


NT AUTHORITY\Authenticated Users
The command completed successfully.

And I have rebooted the entire Windows box more than once since I last changed anything in the Cygwin config, so the config shown should be in effect when Cygwin produced the output posted above.

(I’ve tried what seems like a million things over the years, but this is the mainline approach to the problem as described in the NTSEC article, and I went through *very* carefully last night to do everything I found in the article about how I was supposed to do it, and documented all the things I’ve done to produce this email).

So…HELP! I feel like this is supposed to be an understood problem, and that I have *done* everything the main article says I’m supposed to do — and it hasn’t helped. Did I miss a step or something? Any ideas? I have this across multiple software versions on both sides and multiple hardware platforms and installations; it’s not some one-time thing.

“Flowers of Vashnoi”

It kind of looks like Lois McMaster Bujold has finished and published the novella she read part of back in 2012 at Dreamhaven, which reading I made a video of. At least, the description sounds very like the story she read.

It sounded very promising, and I’ve just finished the book I was in the middle of, so no doubt I’ll find out for myself soon enough!

The novella on Amazon

The reading on YouTube

Kidde Fire Extinguisher Recall

As you may have heard, Kidde has recalled some appallingly huge number of fire extinguishers, whose plastic parts may not hold up to actual use. If you have one, you can still get it replaced, details here.

I had three. Mine were very old (I really should have replaced them, or at least had them tested and refilled, a decade ago), but the model numbers were listed in the recall. I entered a claim on the website (with serial numbers as well), and they accepted it.

Well, late last week, the three replacements came. They’re physically smaller it seems to me (definitely shorter), have metal parts everywhere at the top (except the hose), have a metal rather than plastic mounting bracket, and have a higher rating than my old ones (3A rather than 2A, the new are 40BC, old might have been just 20).

They do want me to ship back the old ones. The same packaging works, and they provide pre-paid shipping labels. I have no idea if they’re asking for all of them back, or if mine are so old they’re suspicious whether I really have them, or whether I happen to be one of the people randomly chosen to send them back so they can be examined. Whichever, they make it very easy, just re-use the same packing and stick on the label and call FedEx. And I’m getting more than $100 worth of new fire extinguishers for free that I should have bought myself some time ago.

I did have some idea of maybe discharging one of the old ones for training (read play) purposes, but since I’m shipping them back I didn’t.

I’m not really clear how they can survive this scale of recall financially. They seem to be covering even very old models that have the problem.

Oh, and the CPSC page linked above says one death reported. While one preventable death is bad of course, that’s not very many to base a decision to categorize a very widely-deployed piece of safety equipment, manufactured for decades, as severely defective to the point of needing recall. I suspect these defective extinguishers have saved hundreds or thousands of lives. I don’t know the numbers on either side of this or any other recall, I don’t really have any definite opinion whether it’s clearly right, clearly wrong, or somewhere in the debatable area. I’m just glad to have gotten my fire extinguishers updated for free.