RE: SMBFS mount's file cannot be made executable
Thanks for the hints! > so...what's your umask? It's 022. As far as it's concerned, umask should only be considered when creating a new file, not to affect existing files' modes (as with the chmod command). At any rate, the "x" bit in mine is unset, so should not be having the issues what you've seen. BTW, what's your Samba server's version? Mine is below: $ /usr/sbin/smbd -V Version 4.7.1 Lastly, I mounted the drives via the explorer and they had been marked as "reconnect at login", so they re-mount for me upon every login and/or after a reboot... And there have been many of both.
Re: SMBFS mount's file cannot be made executable
On 2019/08/14 19:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> This is called by acl_to_any_text, which is called by getfacl. Any >> chance you could try to debug this? >> > > >> I'm about to go on vacation, but I could try to help when I get back. >> > > I'm headed out of town as well. But I get this very same EINVAL for any > drive (/cygdrive/X) > except for the local disk C: (the only local drive my PC has): > > $ mount > ... > S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto) > ... > U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto) > ... > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > BTW, how did you mount those? in explorer, or useing net use? Another question -- what is your umask? I noticed some flakeyness with my execute perms as well but more the opposite. I tried turned execute "off". and only after removing all acls, and renaming it to foo.txt could I get rid of execute. my /etc/fstab shows: # /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 binary,posix=0,user 0 0 and my mount output shows: C:/bin on /usr/bin type ntfs (binary,auto) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) B: on /b type smbfs (binary,user,noumount,auto) D: on /d type smbfs (binary,user,noumount,auto) F: on /f type iso9660 (binary,user,noumount,auto) H: on /h type smbfs (binary,user,noumount,auto) I: on /i type smbfs (binary,user,noumount,auto) M: on /m type smbfs (binary,user,noumount,auto) P: on /p type smbfs (binary,user,noumount,auto) R: on /r type smbfs (binary,user,noumount,auto) S: on /s type smbfs (binary,user,noumount,auto) T: on /t type smbfs (binary,user,noumount,auto) --- /tmp> ll foo* -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* /tmp> chmod -x foo.txt /tmp> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /tmp> cd /h #-- h is an exported samba drive from my server /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> +x foo.txt /h> ll foo.txt -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* --- And it does work (was originally a copy of 'cat.exe') But notice this : /h> chmod -x foo.txt /h> umask 111 /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> chmod +x foo.txt /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt chmod didn't turn on execution flags because I had the execute bit masked out in my umask. I change my umask back to my norm: /h> umask 002 /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> chmod +x foo.txt /h> ll foo.txt -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* Now chmod +x works again. so...what's your umask? -- 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
Re: SMBFS mount's file cannot be made executable
On 2019/08/14 19:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> This is called by acl_to_any_text, which is called by getfacl. Any >> chance you could try to debug this? >> > > >> I'm about to go on vacation, but I could try to help when I get back. >> > > I'm headed out of town as well. But I get this very same EINVAL for any > drive (/cygdrive/X) > except for the local disk C: (the only local drive my PC has): > > $ mount > ... > S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto) > ... > U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto) > ... > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > BTW, how did you mount those? in explorer, or useing net use? Another question -- what is your umask? I noticed some flakeyness with my execute perms as well but more the opposite. I tried turned execute "off". and only after removing all acls, and renaming it to foo.txt could I get rid of execute. my /etc/fstab shows: # /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 binary,posix=0,user 0 0 and my mount output shows: C:/bin on /usr/bin type ntfs (binary,auto) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) B: on /b type smbfs (binary,user,noumount,auto) D: on /d type smbfs (binary,user,noumount,auto) F: on /f type iso9660 (binary,user,noumount,auto) H: on /h type smbfs (binary,user,noumount,auto) I: on /i type smbfs (binary,user,noumount,auto) M: on /m type smbfs (binary,user,noumount,auto) P: on /p type smbfs (binary,user,noumount,auto) R: on /r type smbfs (binary,user,noumount,auto) S: on /s type smbfs (binary,user,noumount,auto) T: on /t type smbfs (binary,user,noumount,auto) --- /tmp> ll foo* -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* /tmp> chmod -x foo.txt /tmp> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /tmp> cd /h #-- h is an exported samba drive from my server /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> +x foo.txt /h> ll foo.txt -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* --- And it does work (was originally a copy of 'cat.exe') But notice this : /h> chmod -x foo.txt /h> umask 111 /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> chmod +x foo.txt /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt chmod didn't turn on execution flags because I had the execute bit masked out in my umask. I change my umask back to my norm: /h> umask 002 /h> ll foo.txt -r--r--r-- 1 34323 Feb 3 2017 foo.txt /h> chmod +x foo.txt /h> ll foo.txt -r-xr-xr-x 1 34323 Feb 3 2017 foo.txt* Now chmod +x works again. so...what's your umask? -- 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
Re: SMBFS mount's file cannot be made executable
On 2019-08-14 19:40, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> You can often figure permissions problems > I already figured where the problem was, in how cygwin convers (or, actually > doesn't) the UNIX's "x" bit into the native DAC for the underlying filesystem > (to store as, again, "x" in the Linux share). > Missing that DACL, SMBD returns "Access denied" for an attempt to execute the > .exe file.> > I don't think that any of the requested output is of any help or indication, > rather than to actually show that the execute permission is missing. > > $ /usr/lib/csih/getVolInfo /cygdrive/z > Device Type: 7 > Characteristics: 10 > Volume Name: > Serial Number : 3112497429 > Max Filenamelength : 255 > Filesystemname : > Flags : 1006f > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: TRUE > FILE_PERSISTENT_ACLS: TRUE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : TRUE > FILE_SUPPORTS_SPARSE_FILES : TRUE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: TRUE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE > FILE_SEQUENTIAL_WRITE_ONCE : FALSE > FILE_SUPPORTS_TRANSACTIONS : FALSE > > $ pwd > /cygdrive/z > > $ gcc hello.c > > $ /usr/lib/csih/getVolInfo /cygdrive/z/a.exe > Device Type: 7 > Characteristics: 10 > Volume Name: > Serial Number : 3112497429 > Max Filenamelength : 255 > Filesystemname : > Flags : 1006f > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: TRUE > FILE_PERSISTENT_ACLS: TRUE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : TRUE > FILE_SUPPORTS_SPARSE_FILES : TRUE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: TRUE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE > FILE_SEQUENTIAL_WRITE_ONCE : FALSE > FILE_SUPPORTS_TRANSACTIONS : FALSE > > $ ls -dl /cygdrive/z/a.exe > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 14 21:30 /cygdrive/z/a.exe > > $ getfacl /cygdrive/z/a.exe > # file: /cygdrive/z/a.exe > # owner: lavr > # group: cppcore > user::rw- > user:lavr:rw- > group::r-- > group:cppcore:r-- > mask::rw- > other::r-- > > $ icacls `cygpath -w /cygdrive/z/a.exe` > Z:\a.exe S-1-22-1-4640:(R,W) > S-1-22-2-5333:(R) > S-1-22-2-5333:(R) > S-1-22-1-4640:(R,W) > Everyone:(R) > > Successfully processed 1 files; Failed processing 0 files Prerequisite for +x is DACL and masks allowing +x on normal file system directories and executables, as Cyggwin is emulating POSIX D/ACLs using Windows D/ACLs: drwxrwxr-x+ 1 SYSTEM SYSTEM 0 Aug 14 18:40 . # file: . # owner: SYSTEM # group: SYSTEM user::rwx user:$USER:rwx group::r-x group:Administrators:rwx group:$GROUP:r-x mask::rwx other::r-x default:user::rwx default:user:$USER:rwx default:group::--- default:group:Administrators:rwx default:mask::rwx default:other::r-x . NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) NT AUTHORITY\SYSTEM:(F) $HOSTNAME\$USER:(RX,W,DC) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Administrators:(RX,W,DC) BUILTIN\$GROUP:(RX) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) $HOSTNAME\$USER:(OI)(CI)(IO)(RX,W,DC) CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) CREATOR GROUP:(OI)(CI)(IO)(DENY)(S,RD,REA,X) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -rwxr-xr-x+ 1 $USER $GROUP 158443 Aug 3 2018 test.exe # file: test.exe # owner: $USER # group: $GROUP user::rwx group::r-x group:SYSTEM:rwx#effective:r-x group:Administrators:rwx#effective:r-x mask::r-x other::r-x test.exe NULL SID:(DENY)(Rc,S,REA,X,DC) $HOSTNAME\$USER:(F) BUILTIN\$GROUP:(RX) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Re: SMBFS mount's file cannot be made executable
> This is called by acl_to_any_text, which is called by getfacl. Any > chance you could try to debug this? > I'm about to go on vacation, but I could try to help when I get back. I'm headed out of town as well. But I get this very same EINVAL for any drive (/cygdrive/X) except for the local disk C: (the only local drive my PC has): $ mount ... S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto) ... U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto) ... Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) ... $ getfacl /cygdrive/u # file: /cygdrive/u # owner: Unknown+User # group: Unknown+Group user::rwx user:lavr:rwx group::r-x mask::rwx other::--- getfacl: /cygdrive/u: Invalid argument $ getfacl /cygdrive/s # file: /cygdrive/s # owner: Unknown+User # group: Unknown+Group user::rwx user:lavr:rwx group::rwx mask::rwx other::--- getfacl: /cygdrive/s: Invalid argument Everything works fine for the drives U: & S: w.r.t execution. $ getfacl /cygdrive/y # file: /cygdrive/y # owner: lavr # group: cppcore user::rwx group::r-x other::r-x getfacl: /cygdrive/y: Invalid argument Drive "Y:" is a share from Linux that has special ACL flags set (I explained in previous posts): acl allow execute always = True making "everything" executable there. -- 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
Re: SMBFS mount's file cannot be made executable
> You can often figure permissions problems I already figured where the problem was, in how cygwin convers (or, actually doesn't) the UNIX's "x" bit into the native DAC for the underlying filesystem (to store as, again, "x" in the Linux share). Missing that DAC, SMBD returns "Access denied" for an attempt to execute the .exe file. I don't think that any of the requested output is of any help or indication, rather than to actually show that the execute permission is missing. $ /usr/lib/csih/getVolInfo /cygdrive/z Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 3112497429 Max Filenamelength : 255 Filesystemname : Flags : 1006f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ pwd /cygdrive/z $ gcc hello.c $ /usr/lib/csih/getVolInfo /cygdrive/z/a.exe Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 3112497429 Max Filenamelength : 255 Filesystemname : Flags : 1006f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ ls -dl /cygdrive/z/a.exe -rw-rw-r--+ 1 lavr cppcore 157753 Aug 14 21:30 /cygdrive/z/a.exe $ getfacl /cygdrive/z/a.exe # file: /cygdrive/z/a.exe # owner: lavr # group: cppcore user::rw- user:lavr:rw- group::r-- group:cppcore:r-- mask::rw- other::r-- $ icacls `cygpath -w /cygdrive/z/a.exe` Z:\a.exe S-1-22-1-4640:(R,W) S-1-22-2-5333:(R) S-1-22-2-5333:(R) S-1-22-1-4640:(R,W) Everyone:(R) Successfully processed 1 files; Failed processing 0 files -- 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
Re: SMBFS mount's file cannot be made executable
On 8/14/2019 4:39 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > I also showed the "getfacl" output for that file and the directory above, > which showed > nothing additional. getfacl failed with EINVAL, as you know. So you can't rely on its output. Ken -- 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
Re: SMBFS mount's file cannot be made executable
On 8/14/2019 10:07 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
wrote:
>249 98510 [main] getfacl 3412 __set_errno: char* __acltotext(aclent_t*,
> int, const char*, char, int):1644 setting errno 22
Here's where the EINVAL is coming from. The source is in sec_acl.cc:
char *
__acltotext (...)
{
if (!aclbufp || aclcnt < 0 || aclcnt > MAX_ACL_ENTRIES
|| (aclcnt > 0 && aclsort32 (aclcnt, 0, aclbufp)))
{
set_errno (EINVAL);
return NULL;
}
This is called by acl_to_any_text, which is called by getfacl. Any
chance you could try to debug this?
I'm about to go on vacation, but I could try to help when I get back.
Ken
Re: SMBFS mount's file cannot be made executable
On 2019-08-14 05:22, Ken Brown wrote: > On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >>> Have you checked the default ACL on the directory containing the file? >> >> No, and there's nothing special there now that I checked. I can change the >> "Read & Execute" for the .exe file from the Windows file properties without >> having to deal with anything special or additional (like inherited >> permissions), so I don't think the containing directory has anything to do >> with it.> > I suspect the containing directory has a lot to do with it. You shouldn't > get an "Invalid argument" error below. > >> $ getfacl /cygdrive/z >> # file: /cygdrive/z >> # owner: lavr >> # group: cppcore >> user::rwx >> group::r-x >> other::r-x >> getfacl: /cygdrive/z: Invalid argument > > Running getfacl under strace might provide a clue as to what the problem is. > You could also try running /usr/lib/csih/getVolInfo.exe on that directory. Running getVolInfo shows you supported operations and options: $ /usr/lib/csih/getVolInfo "$exe" Device Type: 7 Characteristics: 20020 Volume Name: Serial Number : 112776248 Max Filenamelength : 255 Filesystemname : Flags : 3e706ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : TRUE You can often figure permissions problems out yourself by looking at the outputs from: $ ls --color=auto -dl "$exe" $ getfacl "$exe" $ icacls "$(cygpath -m ""$exe"")" and correlating the info, perhaps also with the same commands executed on the containing directory. If you post those output from your system, other may be able to help you. To first approximations: all file access problems are permissions problems; and all programming problems are application programmer array access problems. ;^> You have to first totally eliminate all possibilities of those, before you should bother looking at other prossible causes. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Re: SMBFS mount's file cannot be made executable
> See the '+' at the end of the modes? I saw that, and I also showed the "getfacl" output for that file and the directory above, which showed nothing additional. > Maybe, but we'd still need to know how to get to the result you're seeing. Just take a samba server (4.x) and mount a share with default settings on your Windows box; then try to change the execute permissions for files in there from Cygwin's shell, using chmod -- the simplest. > I hope it's clear to you that the permissions you see on this tab have > nothing to do with the POSIX mode bits you're trying to set from Cygwin. That is completely untrue; the underlying filesystem is still controlled by the OS (Windows) in either case. When the "x" permission is set from under Cygwin, it has to get converted (inside the Cygwin dll) to an appropriate DAC for the native file system layer. That DAC is then sent to the samba server (in case of the smb filesystem), which then either converts it back to the "x" permission (when the SMBD is on Linux) or stores it on the target filesystem, if that's a Windows box. And it works the similar way in the reverse: when a file stat is requested from Cygwin, the SMBD gets the "x" bit, converts it to SMB response (native for Windows DAC for "execute") and sends it back to Windows box, which is then read by Cygwin DLL and gets shown as "x" bit in the POSIX mode. When I just use the file properties dialog, I bypass only one step in the chains I just described, Cygwin DLL. And it works by setting the "x" bit on the server side (Linux). So, that's how I know that something's off in how Cygwin treats that "x" permission when asked to set it on a file. When Windows is about to run an .exe file, it consults the filesystem whether the execute DAC is set. In case of SMBD 4.x, the filesystem will respond "Access denied" if the "x" permission is not found. It used to say "okay" in the previous versions. I quoted the report: https://forge.univention.org/bugzilla/show_bug.cgi?id=33785 So when I asked my Systems guys that the share to be exported with acl allow execute always = True I can now execute any files (even those whose "x" bits are not set at all! -- SMBD clears everything to execute, which is madness). Well, that works around the issue for me, but the question remains as to why when "chmod +x" is given, Cygwin does not cause the "x" permission to be set on the target file if that file resides on smbfs. I suspect there are no provisions in code to do that, but I may be wrong. -- 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
Re: SMBFS mount's file cannot be made executable
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! >> What is your cygdrive mount options? Because default is, apparently, >> "binary,posix=0,user". > I have no idea where they are kept at, and how to change them. This is, as I said, the DEFAULT. To change them, edit /etc/fstab, add the desired line. F.e. none /cygdrive cygdrive binary,posix=0,nouser 0 0 > Also, I couldn't make this work, anyways; yet I thought it should have worked: >> > $ mount -o exec //coredev2/home/lavr /mnt >> > $ mount >> > //coredev2/home/lavr on /mnt type smbfs (binary,exec,user) >> > ... >> > $ cd /mnt >> > $ pwd >> > /mnt >> > $ gcc a.c >> > $ ls -l a.exe >> > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe >> > $ ./a.exe >> > -bash: ./a.exe: Permission denied -- With best regards, Andrey Repin Wednesday, August 14, 2019 22:50:18 Sorry for my terrible english... -- 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
Re: SMBFS mount's file cannot be made executable
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin writes: >> If it's related to the ACL handling then it should start working when >> you remove the ACL on the file with 'setfacl -kb ...' > > There are no special ACLs set on the file (that was just produced by > GCC from the source code, see my first email). You earlier showed this: > $ ls -l a.exe > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe See the '+' at the end of the modes? That's telling you that there is an ACL added to the file and the modes are the result of combining thje actual mode bits with the ACL. As you said, gcc won't add any ACL by itself, so these ACL are the result of inheritable / default ACL. > But I am now convinced that the problem is _entirely_ in Cygwin's corner: Maybe, but we'd still need to know how to get to the result you're seeing. > When I open that file's the "Properties->Security" Windows tab, I can > see that my permissions are "Read" and "Write", yet "Read & Execute" > is NOT checked. When I check it, I see that the file becomes > executable (the "x" bit) from both Cygwin shell and on the Linux side, > too. And after that, I can execute the file from the Cygwin shell. I hope it's clear to you that the permissions you see on this tab have nothing to do with the POSIX mode bits you're trying to set from Cygwin. > So what happens is that when "chmod" (or "creat" with a permission > mask) is called, Cygwin does not honor the "x" bit(s) and does not > convert it to a corresponding proper ACL for the Windows mounted > filesystem (and that ACL, in turn, would have been then sent to SMBD > to get converted there back to the "x" bit in the Unix world). Once > the "x" is there, Windows(via SMBD) obviously allows execution of the > image. Here's a related "bug": Most often that is the result of an inherited ACL mask that clears that bit. Correcting either the default ACL or removing it should then make that problem go away. Default ACL are associated with the parent directory and you're unlikely to be able to change the parent directory modes if it's the root of a file system exported from a filer. Try again in a subdirectory and clear the default ACL with 'setfacl -kb' on that directory before you start doing anything there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Re: SMBFS mount's file cannot be made executable
> I suspect the containing directory has a lot to do with it. Please elaborate what you ground your suspicion on. Like I said previously, I can add "Read & Execute" permissions to the file in question from the Windows file properties dialog, and it gets converted to an "x" on Linux side, then the file becomes executable from on Windows (from either within a Cygwin shell or outside). AFAICT, there's nothing in strace (follows) rather than trying to get info on "Z:" twice. $ strace getfacl /cygdrive/z --- Process 3412 created --- Process 3412 loaded C:\Windows\System32\ntdll.dll at 7ffcdea7 --- Process 3412 loaded C:\Windows\System32\kernel32.dll at 7ffcdde6 --- Process 3412 loaded C:\Windows\System32\KernelBase.dll at 7ffcdbbe --- Process 3412 thread 2912 created --- Process 3412 loaded C:\Cygwin64\bin\cygwin1.dll at 00018004 2 2 [main] getfacl (3412) ** 48 50 [main] getfacl (3412) Program name: C:\Cygwin64\bin\getfacl.exe (windows pid 3412) 25 75 [main] getfacl (3412) OS version: Windows NT-10.0 23 98 [main] getfacl (3412) ** --- Process 3412 loaded C:\Windows\System32\advapi32.dll at 7ffcde99 --- Process 3412 loaded C:\Windows\System32\msvcrt.dll at 7ffcddd2 --- Process 3412 loaded C:\Windows\System32\sechost.dll at 7ffcdd80 --- Process 3412 loaded C:\Windows\System32\rpcrt4.dll at 7ffcde80 --- Process 3412 thread 2120 created --- Process 3412 loaded C:\Windows\System32\cryptbase.dll at 7ffcda7d --- Process 3412 loaded C:\Windows\System32\bcryptprimitives.dll at 7ffcdbe6 37323830 [main] getfacl (3412) sigprocmask: 0 = sigprocmask (0, 0x0, 0x1802FBC50) 6304460 [main] getfacl 3412 open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0xC8, *m 6 1934653 [main] getfacl 3412 user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 2274880 [main] getfacl 3412 open_shared: name S-1-5-21-2137354491-1741569864-122644288-1606.1, n 1, shared 0x18002 (wanted 0x18002), h 0xC4, *m 6 1625042 [main] getfacl 3412 user_info::create: opening user shared for 'S-1-5-21-2137354491-1741569864-122644288-1606' at 0x18002 2455287 [main] getfacl 3412 user_info::create: user shared version AB1FCCE8 1785465 [main] getfacl 3412 fhandler_pipe::create: name \\.\pipe\cygwin-e022582115c10879-3412-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 555520 [main] getfacl 3412 fhandler_pipe::create: pipe read handle 0xDC 245544 [main] getfacl 3412 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-e022582115c10879-3412-sigwait 1185662 [main] getfacl 3412 fhandler_pipe::create: pipe write handle 0xE0 1955857 [main] getfacl 3412 dll_crt0_0: finished dll_crt0_0 initialization --- Process 3412 thread 20940 created 9326789 [main] getfacl 3412 time: 1565789069 = time(0x0) 296818 [sig] getfacl 3412 wait_sig: entering ReadFile loop, my_readsig 0xDC, my_sendsig 0xE0 1556973 [main] getfacl 3412 mount_info::conv_to_posix_path: conv_to_posix_path (\\coredev2\home\lavr, 0x0, no-add-slash) 2087181 [main] getfacl 3412 normalize_win32_path: \\coredev2\home\lavr = normalize_win32_path (\\coredev2\home\lavr) 1167297 [main] getfacl 3412 mount_info::conv_to_posix_path: /mnt = conv_to_posix_path (\\coredev2\home\lavr) 1677464 [main] getfacl 3412 sigprocmask: 0 = sigprocmask (0, 0x0, 0x600018130) 3187782 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 0: not open 1097891 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 1: not open 1188009 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 2: not open 3688377 [main] getfacl (3412) open_shared: name cygpid.3412, n 3412, shared 0x18001 (wanted 0x18001), h 0x108, *m 2 1888565 [main] getfacl (3412) time: 1565789069 = time(0x0) 1508715 [main] getfacl 3412 pinfo::thisproc: myself dwProcessId 3412 1228837 [main] getfacl 3412 environ_init: GetEnvironmentStrings returned 0x113B10 6269463 [main] getfacl 3412 win32env_to_cygenv: 0x6000284F0: ADVISOR_2018_DIR=C:\Program Files (x86)\IntelSWTools\Advisor 2018\ 809543 [main] getfacl 3412 win32env_to_cygenv: 0x600028540: ADVISOR_2019_DIR=C:\Program Files (x86)\IntelSWTools\Advisor 2019\ 1119654 [main] getfacl 3412 win32env_to_cygenv: 0x600028590: ALLUSERSPROFILE=C:\ProgramData 1949848 [main] getfacl 3412 win32env_to_cygenv: 0x6000285C0: APPDATA=C:\Users\lavr\AppData\Roaming 170 10018 [main] getfacl 3412 win32env_to_cygenv: 0x6000285F0: BLASTDB=\\snowman\blast\db\blast 234 10252 [main] getfacl 3412 win32env_to_cygenv: 0x600028620: COMMONPROGRAMFILES=C:\Program Files\Common Files 322 10574 [main] getfacl 3412 win32env_to_cygenv: 0x600028660: COMPUTERNAME=NCBIPC9135 71 10645 [main]
Re: SMBFS mount's file cannot be made executable
On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> Have you checked the default ACL on the directory containing the file? > > No, and there's nothing special there now that I checked. I can change the > "Read & Execute" for the .exe file from the Windows file properties > without having to deal with anything special or additional (like inherited > permissions), so I don't think the containing directory has anything > to do with it. I suspect the containing directory has a lot to do with it. You shouldn't get an "Invalid argument" error below. > $ getfacl /cygdrive/z > # file: /cygdrive/z > # owner: lavr > # group: cppcore > user::rwx > group::r-x > other::r-x > getfacl: /cygdrive/z: Invalid argument Running getfacl under strace might provide a clue as to what the problem is. You could also try running /usr/lib/csih/getVolInfo.exe on that directory. Ken
Re: SMBFS mount's file cannot be made executable
> Have you checked the default ACL on the directory containing the file? No, and there's nothing special there now that I checked. I can change the "Read & Execute" for the .exe file from the Windows file properties without having to deal with anything special or additional (like inherited permissions), so I don't think the containing directory has anything to do with it. $ getfacl /cygdrive/z # file: /cygdrive/z # owner: lavr # group: cppcore user::rwx group::r-x other::r-x getfacl: /cygdrive/z: Invalid argument $ getfacl.exe /mnt # file: /mnt # owner: lavr # group: cppcore user::rwx group::r-x other::r-x getfacl: /mnt: Invalid argument (where /mnt is the same network share mounted with the "exec" option, see previous posts; not sure what EINVAL means there in the output, it does not appear for files -- seems to be only when directories are inquired) -- 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
Re: SMBFS mount's file cannot be made executable
On 8/13/2019 8:53 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> If it's related to the ACL handling then it should start working when >> you remove the ACL on the file with 'setfacl -kb ...' > > There are no special ACLs set on the file (that was just produced by GCC from > the source code, see my first email). Have you checked the default ACL on the directory containing the file? Ken -- 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
Re: SMBFS mount's file cannot be made executable
> If it's related to the ACL handling then it should start working when > you remove the ACL on the file with 'setfacl -kb ...' There are no special ACLs set on the file (that was just produced by GCC from the source code, see my first email). But I am now convinced that the problem is _entirely_ in Cygwin's corner: When I open that file's the "Properties->Security" Windows tab, I can see that my permissions are "Read" and "Write", yet "Read & Execute" is NOT checked. When I check it, I see that the file becomes executable (the "x" bit) from both Cygwin shell and on the Linux side, too. And after that, I can execute the file from the Cygwin shell. So what happens is that when "chmod" (or "creat" with a permission mask) is called, Cygwin does not honor the "x" bit(s) and does not convert it to a corresponding proper ACL for the Windows mounted filesystem (and that ACL, in turn, would have been then sent to SMBD to get converted there back to the "x" bit in the Unix world). Once the "x" is there, Windows(via SMBD) obviously allows execution of the image. Here's a related "bug": https://forge.univention.org/bugzilla/show_bug.cgi?id=33785 I did not investigate in details how Cygwin handles the execute permission, but obviously there's something off. -- 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
RE: SMBFS mount's file cannot be made executable
> What is your cygdrive mount options? Because default is, apparently, > "binary,posix=0,user". I have no idea where they are kept at, and how to change them. Also, I couldn't make this work, anyways; yet I thought it should have worked: > > $ mount -o exec //coredev2/home/lavr /mnt > > $ mount > > //coredev2/home/lavr on /mnt type smbfs (binary,exec,user) > > ... > > $ cd /mnt > > $ pwd > > /mnt > > $ gcc a.c > > $ ls -l a.exe > > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe > > $ ./a.exe > > -bash: ./a.exe: Permission denied -- 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
Re: SMBFS mount's file cannot be made executable
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! >> You need the "exec" mount option. > I thought so too, but how do I give that option to a drive that is > "noumount". I cannot dis- or re-mount it AFAICT. > $ mount > ... > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > $ umount /cygdrive/z > umount: /cygdrive/z: Invalid argument /cygdrive is automount. What is your cygdrive mount options? Because default is, apparently, "binary,posix=0,user". > Also, I tried to mount the same path elsewhere, and with the "exec" > options, and that wouldn't help, either: > $ mount -o exec //coredev2/home/lavr /mnt > $ mount > //coredev2/home/lavr on /mnt type smbfs (binary,exec,user) > ... > $ cd /mnt > $ pwd > /mnt > $ gcc a.c > $ ls -l a.exe > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe > $ ./a.exe > -bash: ./a.exe: Permission denied > (and again, if a.exe is given the "x" perm in the Linux fs, the command above > works) > I think that something's wrong with how (or if) Cygwin translates the "x" > unix execution permission bit to an ACL that is passed thru SMB -- it does > not get transferred to the Linux side correctly. But if set there, then it > gets converted to the execute ACL the right way, and that makes the file > executable on the Windows side... I do not know how is it all implemented, > though; it's just my observation. -- With best regards, Andrey Repin Tuesday, August 13, 2019 21:22:07 Sorry for my terrible english... -- 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
Re: SMBFS mount's file cannot be made executable
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin writes: > I think that something's wrong with how (or if) Cygwin translates the > "x" unix execution permission bit to an ACL that is passed thru SMB -- > it does not get transferred to the Linux side correctly. But if set > there, then it gets converted to the execute ACL the right way, and > that makes the file executable on the Windows side... I do not know > how is it all implemented, though; it's just my observation. If it's related to the ACL handling then it should start working when you remove the ACL on the file with 'setfacl -kb …'. On the other hand you mentioned NetApp, and these can be set up to completely ignore certain DACL, mode or owner changes from clients (with or without raising errors while doing so). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
RE: SMBFS mount's file cannot be made executable
Thanks for responding! > You need the "exec" mount option. I thought so too, but how do I give that option to a drive that is "noumount". I cannot dis- or re-mount it AFAICT. $ mount ... Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) $ umount /cygdrive/z umount: /cygdrive/z: Invalid argument Also, I tried to mount the same path elsewhere, and with the "exec" options, and that wouldn't help, either: $ mount -o exec //coredev2/home/lavr /mnt $ mount //coredev2/home/lavr on /mnt type smbfs (binary,exec,user) ... $ cd /mnt $ pwd /mnt $ gcc a.c $ ls -l a.exe -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe $ ./a.exe -bash: ./a.exe: Permission denied (and again, if a.exe is given the "x" perm in the Linux fs, the command above works) I think that something's wrong with how (or if) Cygwin translates the "x" unix execution permission bit to an ACL that is passed thru SMB -- it does not get transferred to the Linux side correctly. But if set there, then it gets converted to the execute ACL the right way, and that makes the file executable on the Windows side... I do not know how is it all implemented, though; it's just my observation. -- 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
RE: SMBFS mount's file cannot be made executable
> Hi, > > So nobody has any suggestions per this? > > https://cygwin.com/ml/cygwin/2019-08/msg00126.html That's strange. The execution of a file is also controlled by the way the filesystem is mounted and the execution permission granted by chmod is not enough. You need the "exec" mount option. On the drives that have the "user" option automatically implies noexec, nosuid, and nodev, unless overridden by the corresponding option without the "no" prefix. The only issue I can see is that you can execute files on your U: drive and even on your Z: if you give permissions from Linux machine. Maybe Cygwin implementation is not so strict about the permissions. Panos -- 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
