Re: Permission denied ONLY after pulling bundles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Thomas,

Unfortunatly for me i cannot send the files, since there are
restrictions, but thanks for your offer.

At the moment also configuring the repo with --shared=all is not
helping, but i could try to reproduce the problem with a fake repo
shared between windows and linux and see if i get the same error and
at the point i will share the files

with you.

Thanks again.



Rossella

2015-06-08 15:03 GMT+02:00 Thomas Ferris Nicolaisen <tfnico@xxxxxxxxx>:
> On Mon, Jun 8, 2015 at 10:47 AM, Rossella Barletta
> <rossella.barletta@xxxxxxxxx> wrote:
>>
>> So summarizing:
>>
>> 1)  Git repository (bare)  is on Windows on a shared folder
>> 2)  Clone of the repository is on Linux
>> 3) Clone of the repository is on windows
>> 4) I received a bundle made starting by a branch, i pull the bundle on
>> the same branch on Windows, i push the changes , everything ok
>> 5) I go on the clone on Linux, i pull the changes in the branch, make
>> some updates, push...but i get error message about permissions.
>>
>>
>>
>> 4-Alternative)  I received a bundle made starting by a branch, i pull
>> the bundle on the same branche on Linux, i push the changes ,
>> permission errors.
>>
>> The permissions of the files are all set to 777. It is not clear why
>> pushing (after pulling a bundle) on Linux gives permission problems.
>> Even thinking about the user, we have to take in account that before
>> pulling the bundle the same user was used and there was no problem
>> before.
>
> Just to quickly shoot in a thought: I've heard about some similar
> permission problems that occurred when setting up a bare repository
> (on a Linux system). They solved it by re-initializing the repository
> with --shared parameter.
>
> Looking what shared does in the documentation of git-init, the default
> is to use "umask" if --shared is "not specified". I'm not sure if even
> Windows has any sort of umask.. In any case, my wild guess is that
> some operations triggers the remote Git process/user to create new
> files (repack, gc, etc) that get restricted permissions on Windows.
>
> How do you set permissions to 777 on Windows? I didn't know Windows
> uses the same kind of permissions there.. Anyhow, is it possible for
> you to reset the permissions again so that the pushing works again
> (until the next bundle)? If you can do so, configure the bare
> repository to have --shared=all, and see if that helps.
>
> For more help, please share with us the following:
>
> * A complete zip of the bare repository where pushing still works
> (shared over Internet, not as email attachment)
> * The commands you are executing, and their complete output
> * A complete zip of the bare repository where pushing no longer works
> * The complete configuration of the Linux client where the push is
> failing (git config -l)
>
>
> Also noting that this seems to be cross-posted to StackOverflow:
> http://stackoverflow.com/questions/30500226/git-push-fatal-write-error-permission-denied-after-pulling-a-bundle



-- 
Rossella
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]