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
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 o
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 o
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, a
> 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 d
> 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
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:
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 *
__acltot
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
> 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 de
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 l
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
> 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 th
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 proper
> 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
perm
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 so
> 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
> 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
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)
> $ um
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 conve
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:
> 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
22 matches
Mail list logo
