If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.

I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.

I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.

Just ran into this issue on a freshly installed Ubuntu 16.04 docker container.
Actually it's just the package phpX.Y-xml what is missing.
In my case it was php7.2 so all I needed to do was:

sudo apt install php7.2-xml

(No extra repositories needed...)

We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).

This report is generally unclear / hard to reproduce / unusual so I'm not sure how to move forward. It's likely mooted by D20181.

If you want me to look at something, file a report on Discourse with reproduction steps that I can follow to reproduce the issue. I don't need any other discussion or context. I do need working reproduction steps.

No.

@epriestley I have seen you working on Mercurial stuff. Can you take a look at my findings above?

Ok, I think the problem is here: https://github.com/phacility/phabricator/blob/master/src/applications/diffusion/controller/DiffusionServeController.php#L816

I've managed to find the root of the problem, I think. Here is the actual error message that arises somwhere deep in Phabricator and then gets cut turning into non-informative ** unknown exception encountered, please report by visiting:

I still having this problem. @rafaelrabeloit, had you chance to fix or work-around this?

No clue how to reproduce this.

This doesn't seem actionable and is likely mooted by T13098.

I believe this was fixed by D17558 and discussed in T11050.

i met the same issue, and i found the root cause was the OpenSSH upstream issue.

The company I work for doesn't use Phabricator anymore. If I recall correctly the issue happens when an error occurs when creating the working copy. So DryDock create a copy 'copy-123' for example and then if an error occur (during the creation of the working copy for example can't fetch the repository), the build is stopped and the folder 'copy-123' is not deleted. DryDock will retry after 15s and create another copy 'copy-124'. So you can end up with millions of folders after a couple of hours.

I'm unable to reproduce this by following the instructions provided, at least after changes in T13073. Here's what I did:

This is possibly connected to T9548 but we don't know how to reproduce this and can't fix issues we can't reproduce.

We don't have reproduction steps for this and thus can't move forward.

We haven't received the information we need to move forward, so I'm going to close this. Feel free to follow up here or open a new task if you're able to provide detailed reproduction instructions we can use to reproduce the issue locally.

I can't reproduce this. Here's what I tried:

Thanks for updating your report with reproduction instructions, they were very helpful in reproducing and fixing the bug.

I have added some more details. Let me know if you need any more.

Ok sorry, I will improve the report.

We haven't received more information on this, so we don't know how to reproduce it and can't move forward. Feel free to file a new issue in the future with complete reproduction steps, per above.

We don't know how to reproduce this, so we can't move forward, and haven't received more information in several days.

We don't know how to reproduce this, and haven't received more information in several days.

Next steps:

This doesn't appear to describe a bug in Phabricator.

I'm just going to nuke this since there's no repro. This workflow has also been rewritten on the experimental branch and the specific error encountered here should now be impossible.

@exp10r3r you still need to provide reproduction steps. Based on the ones provided, I cannot reproduce any issue using a new/clean install on Phacility or locally. That doesn't mean there isn't a bug to fix, but without the specifics needed to observe and troubleshoot the issue, we have no idea where to start or what to look for. Because we provide support for free, it's on report submitters to fill in all the details needed here. We can't assist with that. No other install is reporting this issue, so it's unlikely due to any change from the upstream.

Specifically, reproduction steps are a set of complete, detailed steps we can follow and see the same issue you are seeing locally. Bonus if you've taken a new, clean image and reproduced the issue.

Currently, Fixes T123 in a commit message means this: