Re: Permission denied ONLY after pulling bundles

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

 



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
--
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]