Jump to content


User cannot add files to commons

commons

  • Please log in to reply
8 replies to this topic

#1 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 26 January 2015 - 10:41 PM

I get the " The server was unable to accept your file valet choice, please try again, then contact support. " error.

I installed the commons.ova for the Perforce service and the Commons service as separate VM's as per the Installation Guide. I tried this several times, and finally got something to work when using commonssuper as the admin account when setting up Commons.

Point is that only the commonssuper user can upload files. As soon as I add a user, create a space and try to upload a file, I get the above error. Also, the files that are uploaded by the commons user to a space owned by the user, can only be seen by the commonssuper.

I don't quite see what I did wrong. Originally I followed the exact Installation instructions using the default commonsadmin account, but then no user was able to create a space.

What is causing this?

I have set up p4 service to listen at port 16445, and the webserver listens at port 16444. Reason for this is I want to forward appropriate ports on the router to the machines running the services.

Any ideas or suggestions?

Cheers,
Arthur

#2 P4Shimada

P4Shimada

    Advanced Member

  • Members
  • PipPipPip
  • 831 posts

Posted 29 January 2015 - 09:35 PM

Hi Arthur,

Thanks for sending the exact error message. Sorry you are having some troubles with the Commons setup. Which version of Commons are you using (The version info can be accessed from the "About" link.  Before logging in, scroll to the bottom to see the link.  After logging in, use the "Hello USER" dropdown menu.)?

Have you looked at the Commons log file when this happened? (On a commons.ova based VM, the logs are rotated by day and restart and would be named like /var/log/commons/YYYY_MM_DD.stderrout.log)

I have known of this error message before when a user had a trigger that was causing submit failures. Do you have any triggers setup on your server?

#3 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 31 January 2015 - 03:45 PM

I am running: Version: 2014.1.940325 from an ova package. There is a warning in the stderr log, see this screenshot: https://www.dropbox....nshot.tiff?dl=0

I am running everything straight out of the box, no special things added. I did change the ports the perforce and the commons server are running on to 16445 and 16444 respectively, but the errors also occur with the original ports, so I gather that's not the culprit. The SSL warnings may indicate something though.

#4 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 07 February 2015 - 01:08 PM

Any ideas?

#5 Tubah

Tubah

    Advanced Member

  • Staff
  • 46 posts

Posted 09 February 2015 - 08:56 PM

The warnings in your screenshot aren't anything unusual.  Ignore for now.

Using alternate ports are OK, just update commons.config's property for commonsURL to include your new port 16444 (/opt/jetty/conf/commons.config on the ova). This config file also has the guestLogin and password - make sure those are correct.

This might be a protections table issue on the commons server.  If you can check out the latest commons log file as Shimada suggested when the upload fails -/var/log/commons/YYYY_MM_DD.stderrout.log - we can get a better idea of what went wrong.  The stack traces can be quite long - look at the last (bottom) one or post them all here.

Or log a call to Support.

> the files that are uploaded by the commons user to a space owned by the user, can only be seen by the commonssuper.

Check the space properties - make access "Open" to all.

#6 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 10 February 2015 - 12:12 PM

Attached a screen shot. I can't get the shared folder stuff to work in the host (Mac). https://www.dropbox....nsLog.tiff?dl=0

#7 Tubah

Tubah

    Advanced Member

  • Staff
  • 46 posts

Posted 10 February 2015 - 06:12 PM

That's a permission problem.  The upload is trying to save the file to a depot dir that the user doesn't have permission to access or write to.

Did you hook up Commons to your existing Perforce server instance?    Or did you start with a commons.ova and just leave the perforce server running?  What's the output from "p4 protect -o" ??

For example, if you create a Space (take the defaults), Commons will upload the to dirs in the commons depot, e.g., //commons/spaces/1/files/...
The commons.ova has a trigger that creates a protection table entry for group "commons_group_1" access to the files in //commons/spaces/1/files/...
If the user is a member of the space then the user is in group commons_group_1 and can access the files.

#8 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 10 February 2015 - 09:55 PM

I figured that one out as well. Here's what I did: a new install with both commons & perforce in the same VM. That works ok. But I don't want to do it that way since upgrading the server is less easy within one VM. I am not using my existing p4 instance, as I want to keep the two apart and liked the idea of having commons run entirely as a VM.

I will try again tomorrow to set up both perforce and commons in a separate VM as I did before. The access rights as you mention, I saw in p4admin connected to the perforce VM. I also tried creating a user with p4admin, but also there, same problem.

Also tried granting the users superuser rights, but that did not work either.

The fact that when I have both p4 and commons in the same VM everything works ok, means that the communication between the two VMs is not working properly. Once I have done a clean install, I'll report back the output of p4 protect, and make some screenshots of the results in p4admin.

#9 acjv

acjv

    Member

  • Members
  • PipPip
  • 11 posts

Posted 12 February 2015 - 11:43 AM

Update:

I have reinstalled the perforce and commons service in separate VM's. The only thing I did differently this time is keeping the connection between p4 and commons to non-SLL. Before I used the SSL connection.

It now works correctly having separate VM's running on the same machine (the reason why I decided to leave out SSL). Not sure if the behavior I was seeing is connected to SSL being used between the two VM's. The errors are gone, and users can add files en update them.





Also tagged with one or more of these keywords: commons

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users