Permissions issues on SMB shares from Cygwin

[David Dyer-Bennet]

Not really sure when things changed; old directories still seem to work fine, and most things work fine from windows, but anything I create from Cygwin can't be accessed by Cygwin unless I manually reset the permission in Windows (so I sort-of have a workaround; unfortunately that workaround doesn't work with testing and build scripts since it requires manual intervention).

I may know what the underlying problem is, though: Windows accesses the SMB shares under my server identity (FSFS\ddb in this case), whereas Cygwin seems to be accessing them as nobody, maybe even NOBODY.

P: is exported from FSFS via SMB. Windows sees this directory as follows:

As a result...when I create a subdirectory, and then try to create a file in that subdirectory, it fails:

 

[Ericloewe]

So what's going on? Is Windows handling the actual SMB connection for the folder Cygwin is using? That must be a nightmare... A compatibility layer mapping Unix permissions onto Windows permissions, which are mapped onto ZFS ACLs by Samba.

 

[David Dyer-Bennet]

Yep, Windows is doing it all so far as I can tell. Same problem if I use the UNC path //fsfs/ddb/Documents instead of the mapped Windows drive letter P: No sign of anything special for this drive in /etc/fstab.

The problem seems to be simply that Cygwin is presenting the wrong user; but Windows is somehow still getting the data through.

This particular hack (fix-up on some keywording issues in a big photo database that's over a decade old) depends on Windows software both for the photo index app itself (including, I'm pretty sure, having to send it DDE commands to accomplish a few particular things), and for directly accessing its database format (access), so doing it "somewhere else" isn't an option.

I'll ask in the Cygwin groups too of course, no idea if I'm really more likely to find the expertise to solve both parts of the issue together here, there, not at all, or what.

Or I suppose I could try Bash for Windows, or maybe do the test scripts in Windows Power Shell (which I'd have to learn). Just what I need, major tool changes and learning curves to do a one-shot repair hack.

 

[anodos]

Yep, Windows is doing it all so far as I can tell. Same problem if I use the UNC path //fsfs/ddb/Documents instead of the mapped Windows drive letter P: No sign of anything special for this drive in /etc/fstab.

The problem seems to be simply that Cygwin is presenting the wrong user; but Windows is somehow still getting the data through.

This particular hack (fix-up on some keywording issues in a big photo database that's over a decade old) depends on Windows software both for the photo index app itself (including, I'm pretty sure, having to send it DDE commands to accomplish a few particular things), and for directly accessing its database format (access), so doing it "somewhere else" isn't an option.

I'll ask in the Cygwin groups too of course, no idea if I'm really more likely to find the expertise to solve both parts of the issue together here, there, not at all, or what.

Or I suppose I could try Bash for Windows, or maybe do the test scripts in Windows Power Shell (which I'd have to learn). Just what I need, major tool changes and learning curves to do a one-shot repair hack.

What do the permissions look like from the FreeNAS side? Post getfacl output.

 

[anodos]

Have you tried mounting the share from within cygwin instead of trying to muck around with mapped network drives?

 

[David Dyer-Bennet]

Have you tried mounting the share from within cygwin instead of trying to muck around with mapped network drives?

No, but it's something else to try; I'll check out the option. Currently trying two test shares created from scratch to make sure there isn't some weird historical component to their permissions or other settings that may be contributing to this problem.

(The email notification version of your message had more amusing character ;-) )

 

[David Dyer-Bennet]

What do the permissions look like from the FreeNAS side? Post getfacl output.

Extremely vanilla:

Code:

[ddb@fsfs ~]$ getfacl /mnt/zp1/ddb/Documents/work/tpdbfix/captest/
# file: /mnt/zp1/ddb/Documents/work/tpdbfix/captest/
# owner: ddb
# group: ddb
  everyone@:rwxpDdaARWcCo-:fd-----:allow
  group@:rwxpDdaARWcCo-:fd-----:allow
  owner@:rwxpDdaARWcCo-:fd-----:allow
[ddb@fsfs ~]$

(That's not how they've been or will be long-term, but while messing with this I've been trying to find workarounds as well as real solutions -- and even setting "everyone" with full permissions isn't working.)

 

[David Dyer-Bennet]

Have you tried mounting the share from within cygwin instead of trying to muck around with mapped network drives?

No, but it's something else to try; I'll check out the option. Currently trying two test shares created from scratch to make sure there isn't some weird historical component to their permissions or other settings that may be contributing to this problem.

 

[David Dyer-Bennet]

Mounting separately from Cygwin makes no difference, even on a test share not already mounted in Windows.

 

[anodos]

Mounting separately from Cygwin makes no difference, even on a test share not already mounted in Windows.

Have you tried mapping your samba accounts per instructions here: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba

Relevant part

For home users without any Windows domain or LDAP server per RFC 2307, but with a Linux machine running Samba, just add this information to your SAM account. Assuming the uid of your Linux user account is 505 and the gid of your primary group is, say, 100, just add the values to your SAM user and group accounts. The following example assumes you didn't already add something else to the comment field.

To your user's SAM comment (remember: called Description in the GUI), add:

<cygwin group="Users" unix="505"/>

To the Users group SAM comment add:

<cygwin unix="100"/>

This should be sufficient to work on your Samba share and to see all files owned by your Linux user account as your files.

 

[David Dyer-Bennet]

Have you tried mapping your samba accounts per instructions here: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba

Relevant part

I don't know; I can't tell. That's thousands of words of incredibly detailed information, much of it addressing situations that aren't mine. It uses terms that it doesn't define, particularly "SAM account", and which I have not been able to google up anything meaningful on (most of the hits on that phrase aren't even computer-related). It sounds like I have to do something somewhere, and that a GUI is involved (which means it's not in cygwin), but it doesn't give me the slightest clue as to where this place is. I'm sure the information is in there somewhere, but it seems to be written for people who aren't me -- and I've enabled AD authentication on multiple linux boxes and web servers, set up an LDAP server to support multiple Unix boxes with shared user space, configured NFS to work across that, and done all kinds of things in this vague area. But that document seems to be speaking greek, or something. It needs to define its terms, and it probably needs to separate out the different cases a bit more.

 

[David Dyer-Bennet]

Have you tried mapping your samba accounts per instructions here: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba

Relevant part

Okay, have actually made considerable progress on understanding that document, at the cost of the rest of my night and a chunk of today. I don't yet have a definite win, may not tonight yet, but wanted to update to say I am still slogging along. It continues to annoy me that the primary use-case I've had for Samba for a couple of decades now tends to be scattered through the documentation of the other cases that I've never had to worry about (sharing with Windows without Active Directory; AD applies to some systems at work, but not all of them, and to no systems in my or many other homes I have any info from).

 

[David Dyer-Bennet]

Have you tried mapping your samba accounts per instructions here: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba

Relevant part

And now, yes, I have tried that, and it doesn't do anything.

I've added a description / comment to my Windows user account using that pseudo-xml format and saying inside it unix="1001" (where that's the uid of my user account on the FreeNAS box). I've put a "gecos: desc" line into /etc/nsswitch.conf. I've restarted my Cygwin session. And nothing appears to have changed. Am I missing some basic step?

Code:

ddb@ddblap7:/cygdrive/r/fanphotos
$ net user ddb
User name					ddb
Full Name
Comment					  <cygwin unix="1001" group="Users"/>
User's comment
Country/region code		  000 (System Default)
Account active			   Yes
Account expires			  Never

Password last set			2/24/2018 11:56:27 PM
Password expires			 Never
Password changeable		  2/24/2018 11:56:27 PM
Password required			No
User may change password	 Yes

Workstations allowed		 All
Logon script
User profile
Home directory
Last logon				   6/4/2018 7:31:44 PM

Logon hours allowed		  All

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


$ ls -l //fsfs/bdr
total 0
drwxrwxr-x+ 1 Unknown+User Unix_Group+1001 0 May 13 17:44 DaveRommPhotos
drwxrwxr-x+ 1 Unknown+User Unix_Group+1001 0 Jun  4 20:25 fanphotos
ddb@ddblap7:/cygdrive/r/fanphotos
$ getfacl //fsfs/bdr/DaveRommPhotos/
# file: //fsfs/bdr/DaveRommPhotos/
# owner: Unknown+User
# group: Unix_Group+1001
user::rwx
group::rwx
other:r-x
default:user::rwx
default:group::rwx
default:group:Unix_Group+1001:rwx
default:mask:rwx
default:other:r-x

ddb@ddblap7:/cygdrive/r/fanphotos
$ id
uid=197611(ddb) gid=197121(None) groups=197121(None),545(Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This Organization),113(Local account),66048(LOCAL),262154(NTLM Authentication),401408(Medium Mandatory Level)
ddb@ddblap7:/cygdrive/r/fanphotos

$ 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 https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
#
# 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

 

[acquacow]

I'm dealing with the same issues here. I have no issues with mapped drives to my synology NAS's, but I just built a freenas box on a 10gig network hoping to speed up my backup scripts, but ran into the permissions issue.

I'll be digging into this shortly, just wanted to let you know you are not alone.

 

[acquacow]

Alright, figured it out

In cygwin:
First I did a mkpasswd --local > /etc/passwd
mkgroup --local > /etc/group

I then did an ls -ln on /cygdrive/s/ and found my user ID, the default group windows shows is "None" but this is okay, as I have the directory perms on FreeNAS set to my user and wheel as the default group. Cygwin won't be changing that.

Ignore the messy files, this is all just test data while I was playing around.

dwujcik@Dave ~
$ ls -ln /cygdrive/s/
total 31947776
drwxr-xr-x 1 4294967295 197121 0 Sep 20 21:09 Backup
-rw-r--r-- 1 4294967295 197121 621805568 Sep 22 2015 CentOS_6.5-Fusion_4.1.1-LiveCD.iso
-rw-r--r-- 1 4294967295 197121 7537496064 Sep 10 18:23 ElCapitan.iso
-rw-r--r-- 1 4294967295 197121 1631584256 Jan 30 2018 Fedora-Workstation-Live-x86_64-27-1.6.iso
-rw-r--r-- 1 4294967295 197121 727638827 Feb 10 2016 'FEW WORDS - Candide Thovex.mp4'
-rw-r--r-- 1 4294967295 197121 633833472 Mar 27 14:23 FreeNAS-11.1-U4.iso
drwxr-xr-x 1 4294967295 197121 0 Sep 10 15:47 home
-rw-r--r-- 1 4294967295 197121 733839360 Oct 28 2012 KNOPPIX_V6.7.1CD-2011-09-14-EN.iso
-rw-r--r-- 1 4294967295 197121 4856893440 Nov 15 2016 MountainLion.iso
-rw-r--r-- 1 4294967295 197121 7516225536 Sep 10 15:49 OSX_InstallESD_10.10.3_14D131.iso
-rw-r--r-- 1 4294967295 197121 4059037696 Sep 22 2017 rhel-server-7.4-x86_64-dvd.iso
-rw-r--r-- 1 4294967295 197121 1048576000 Sep 10 18:44 test.txt
-rw-r--r-- 1 4294967295 197121 12 Sep 20 21:08 testing
-rw-r--r-- 1 4294967295 197121 3319478272 Feb 6 2017 'Windows 7 Pro OEM X17-24281.iso'


I changed my userid in /etc/passwd (in cygwin) to match the one reported in my ls and created a group with the group id that showed up in the ls.

$ cat /etc/passwd |grep dwujcik
dwujcik:*:4294967295:4278190080:U-DAVE\dwujcik,S-1-5-21-169477345-3562302959-3774684919-1001:/home/dwujcik:/bin/bash


The last trick is to edit /etc/fstab for /cygwin and add the noacl option

$ cat /etc/fstab
# /etc/fstab
#
# 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 https://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0


Now ls -l gives me proper user/group and when I create files, it doesn't facl them down to read only.

dwujcik@Dave /cygdrive/s
$ ls -l
total 31947776
drwxr-xr-x 1 dwujcik None 0 Sep 20 21:09 Backup
-rw-r--r-- 1 dwujcik None 621805568 Sep 22 2015 CentOS_6.5-Fusion_4.1.1-LiveCD.iso
-rw-r--r-- 1 dwujcik None 7537496064 Sep 10 18:23 ElCapitan.iso
-rw-r--r-- 1 dwujcik None 1631584256 Jan 30 2018 Fedora-Workstation-Live-x86_64-27-1.6.iso
-rw-r--r-- 1 dwujcik None 727638827 Feb 10 2016 'FEW WORDS - Candide Thovex.mp4'
-rw-r--r-- 1 dwujcik None 633833472 Mar 27 14:23 FreeNAS-11.1-U4.iso
drwxr-xr-x 1 dwujcik None 0 Sep 10 15:47 home
-rw-r--r-- 1 dwujcik None 733839360 Oct 28 2012 KNOPPIX_V6.7.1CD-2011-09-14-EN.iso
-rw-r--r-- 1 dwujcik None 4856893440 Nov 15 2016 MountainLion.iso
-rw-r--r-- 1 dwujcik None 7516225536 Sep 10 15:49 OSX_InstallESD_10.10.3_14D131.iso
-rw-r--r-- 1 dwujcik None 4059037696 Sep 22 2017 rhel-server-7.4-x86_64-dvd.iso
-rw-r--r-- 1 dwujcik None 1048576000 Sep 10 18:44 test.txt
-rw-r--r-- 1 dwujcik None 12 Sep 20 21:08 testing
-rw-r--r-- 1 dwujcik None 3319478272 Feb 6 2017 'Windows 7 Pro OEM X17-24281.iso'


Vs what I see in FreeNAS:

[root@freenas /mnt/SSD]# ls -l
total 63882147
drwxrwxr-x+ 3 dwujcik wheel 3 Sep 20 18:09 Backup
-rwxrwxr-x+ 1 dwujcik wheel 621805568 Sep 22 2015 CentOS_6.5-Fusion_4.1.1-LiveCD.iso
-rwxrwxr-x+ 1 dwujcik wheel 7537496064 Sep 10 15:23 ElCapitan.iso
-rwxrwxr-x+ 1 dwujcik wheel 1631584256 Jan 30 2018 Fedora-Workstation-Live-x86_64-27-1.6.iso
-rwxrwxr-x+ 1 dwujcik wheel 727638827 Feb 10 2016 FEW WORDS - Candide Thovex.mp4
-rwxrwxr-x+ 1 dwujcik wheel 633833472 Mar 27 11:23 FreeNAS-11.1-U4.iso
drwxrwxr-x+ 3 dwujcik wheel 3 Sep 10 12:47 home
-rwxrwxr-x+ 1 dwujcik wheel 733839360 Oct 28 2012 KNOPPIX_V6.7.1CD-2011-09-14-EN.iso
-rwxrwxr-x+ 1 dwujcik wheel 4856893440 Nov 15 2016 MountainLion.iso
-rwxrwxr-x+ 1 dwujcik wheel 7516225536 Sep 10 12:49 OSX_InstallESD_10.10.3_14D131.iso
-rwxrwxr-x+ 1 dwujcik wheel 4059037696 Sep 22 2017 rhel-server-7.4-x86_64-dvd.iso
-rwxrwxr-x+ 1 dwujcik wheel 1048576000 Sep 10 15:44 test.txt
-rwxrwxr-x+ 1 dwujcik wheel 12 Sep 20 18:08 testing
-rwxrwxr-x+ 1 dwujcik wheel 3319478272 Feb 6 2017 Windows 7 Pro OEM X17-24281.iso


It's possible the only change needs to be the "noacl" in the /etc/fstab, but I ended up doing that last, so I'm not sure.

Easy enough to test once my huge rsync finishes... just need to move the passwd and group files elsewhere and restart the cygwin shell.

There may be a cleaner way to do this, but I think this works for my needs, so I might not mess with it further.

I'm open to suggestions though.

-- Dave