Results 1 to 10 of 14

Thread: Documents permissions messed up

Hybrid View

  1. #1
    Join Date
    Jul 2006
    Location
    Reno, NV, USA
    Posts
    203
    Rep Power
    9

    Default Documents permissions messed up

    Hi,

    I've got ZCS 4.5 server than was upgraded from 4.0.5 (domain documents were created in the 4.0.x timeframe).

    When I go to the domain in Admin UI and view documents, permissions are all messed up and I can't save. For example the public (no password) should only show 'view', but it has 'view','edit','add','remove'. If you double-click to edit public, only a checkbox for 'view' shows. How can I reset all these permissions?

    I don't have anything in there that I care about, so I'm happy to start over.

    I have run:
    zmprov mc default zimbraFeatureNotebookEnabled TRUE
    zmprov mcf zimbraNotebookAccount wiki@domain.com
    zmprov in wiki@domain.com password /opt/zimbra/wiki/Template Template

    And all the commands run successfully, but the permissions are still hosed.
    Attached Images Attached Images
    Last edited by jdell; 01-26-2007 at 03:59 PM.

  2. #2
    Join Date
    Sep 2005
    Location
    Tucson - San Francisco - Moscow
    Posts
    127
    Rep Power
    10

    Default

    Quote Originally Posted by jdell View Post
    Hi,

    I've got ZCS 4.5 server than was upgraded from 4.0.5 (domain documents were created in the 4.0.x timeframe).

    When I go to the domain in Admin UI and view documents, permissions are all messed up and I can't save. For example the public (no password) should only show 'view', but it has 'view','edit','add','remove'. If you double-click to edit public, only a checkbox for 'view' shows. How can I reset all these permissions?

    I don't have anything in there that I care about, so I'm happy to start over.

    I have run:
    zmprov mc default zimbraFeatureNotebookEnabled TRUE
    zmprov mcf zimbraNotebookAccount wiki@domain.com
    zmprov in wiki@domain.com password /opt/zimbra/wiki/Template Template

    And all the commands run successfully, but the permissions are still hosed.
    It seems like a UI bug that I also spotted couple of days ago. The permissions table does not reflect correct info until you hit save and reload the UI. The dialog that pops up when you double click the permission row in the table actually shows correct info. So try this. Double click the permission row in the table, select the checkboxes that you need and then save the domain settings (click save button in the toolbar). After you saved, reload the app and see if the permissions table is still messed up.
    Greg
    Bugzilla - Wiki - Downloads - Before posting... Search!
    P.S.: don't forget to vote on this bug
    add Samba LDAP entries to Exchange Migration Tool

  3. #3
    Join Date
    Jul 2006
    Location
    Reno, NV, USA
    Posts
    203
    Rep Power
    9

    Default

    Quote Originally Posted by Greg View Post
    It seems like a UI bug that I also spotted couple of days ago. The permissions table does not reflect correct info until you hit save and reload the UI. The dialog that pops up when you double click the permission row in the table actually shows correct info. So try this. Double click the permission row in the table, select the checkboxes that you need and then save the domain settings (click save button in the toolbar). After you saved, reload the app and see if the permissions table is still messed up.
    Greg
    My situation seems to be a bit stickier than that. I can't fix the 'public (no password)' permissions nor can I change any of the other permissions.

    Any change via the 'edit' button, to any of these attributes and subsequent 'save' results in this:

    Code:
    Message:  invalid request: missing required attribute: d
    com.zimbra.common.service.ServiceException: invalid request: missing required attribute: d
    	at com.zimbra.common.service.ServiceException.INVALID_REQUEST(ServiceException.java:182)
    	at com.zimbra.soap.Element.checkNull(Element.java:179)
    	at com.zimbra.soap.Element.getAttribute(Element.java:158)
    	at com.zimbra.cs.service.mail.FolderAction.handleFolder(FolderAction.java:182)
    	at com.zimbra.cs.service.mail.FolderAction.handle(FolderAction.java:108)
    	at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:262)
    	at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:153)
    	at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:84)
    	at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:223)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    	at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:162)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
    	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
    	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
    	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
    	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
    	at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
    	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
    	at java.lang.Thread.run(Thread.java:595)
    
    Error code:  service.INVALID_REQUEST
    Method:  ZaDomainController.prototype.saveChangesCallback
    Details:soap:Sender
    Any way through zmprov to nuke/reset these permissions?

  4. #4
    Join Date
    Sep 2005
    Location
    Tucson - San Francisco - Moscow
    Posts
    127
    Rep Power
    10

    Default

    Quote Originally Posted by jdell View Post
    Any way through zmprov to nuke/reset these permissions?
    zmprov cannot change these permissions, however if you just want to recreate/nuke these permissions, and you DO NOT care about documents that are currently there, you can do this:

    zmprov md yourdomain.com zimbraNotebookAccount ""

    this will empty zimbraNotebookAccount in yourdomain.com
    after you run this command, open (or reopen) the domain view in the admin UI and Create Documents button should get enabled. Go through the Documents creation wizard and set the desired permissions. In the wizard use a different account name for wikis, i.e. wiki2@yourdomain.com instead of wiki@yourdomain.com, or delete the wiki account before you start the wizard. When you finish the wizard it will recreate wiki folders and permissions.
    Bugzilla - Wiki - Downloads - Before posting... Search!
    P.S.: don't forget to vote on this bug
    add Samba LDAP entries to Exchange Migration Tool

  5. #5
    Join Date
    Jul 2006
    Location
    Reno, NV, USA
    Posts
    203
    Rep Power
    9

    Default

    Quote Originally Posted by Greg View Post
    zmprov cannot change these permissions, however if you just want to recreate/nuke these permissions, and you DO NOT care about documents that are currently there, you can do this:

    zmprov md yourdomain.com zimbraNotebookAccount ""

    this will empty zimbraNotebookAccount in yourdomain.com
    after you run this command, open (or reopen) the domain view in the admin UI and Create Documents button should get enabled. Go through the Documents creation wizard and set the desired permissions. In the wizard use a different account name for wikis, i.e. wiki2@yourdomain.com instead of wiki@yourdomain.com, or delete the wiki account before you start the wizard. When you finish the wizard it will recreate wiki folders and permissions.
    Ok, I got this to work (mostly), but I couldn't use wiki@mydomain.com even though I deleted it. There must be some trace of that account somewhere even though it didn't show up in the account list after deleting, and I did a full zmcontrol stop/start with same result.

    Finally, I found that creating with wiki2, then renaming to wiki worked (almost).

    So, for sake of clarity, I did the following:
    1) zmprov md yourdomain.com zimbraNotebookAccount ""
    2) delete wiki@mydomain.com account
    3) zmcontrol stop/start
    4) create documents for domain with account wiki2 (using wiki gives error).
    5) changed account name from documents admin UI back to wiki (this deletes wiki2 account and creates wiki account).

    The problem is that when I login to the documents page, the email address still shows as wiki2 in the upper right corner (in client documents UI).

    I did a full zmcontrol stop/start again, and reloaded in browser, but client docs UI still shows wiki2 where admin UI shows wiki (wiki2 account doesn't exist according to admin UI). I think if I can find where wiki2 is still lingering that I can call this cleaned up.

    Any ideas? LDAP, MySQL, configs files, Cache?

    I got this on ldap query, so I don't think it is from LDAP
    Code:
    zimbra@zimbra->zmprov gacf | grep wiki
    zimbraNotebookAccount: wiki@mydomain.com
    and this on local config:
    Code:
    zimbra@zimbra->zmlocalconfig | grep wiki 
    wiki_enabled = false
    wiki_user = wiki
    So, everything is working ok, but I'm concerned that it is displaying the wrong account the client documents UI.

  6. #6
    Join Date
    Sep 2005
    Location
    Tucson - San Francisco - Moscow
    Posts
    127
    Rep Power
    10

    Default

    Quote Originally Posted by jdell View Post
    So, everything is working ok, but I'm concerned that it is displaying the wrong account the client documents UI.
    The only place where it could be left is global config
    run
    zmprov> gcf zimbraNotebookAccount

    to see if it is there
    Bugzilla - Wiki - Downloads - Before posting... Search!
    P.S.: don't forget to vote on this bug
    add Samba LDAP entries to Exchange Migration Tool

Similar Threads

  1. Documents & Notebooks Woes
    By torusgrp in forum Administrators
    Replies: 0
    Last Post: 05-11-2007, 10:19 PM
  2. Replies: 26
    Last Post: 02-12-2007, 06:23 PM
  3. Documents Feature Messed up
    By frogstarr78 in forum Installation
    Replies: 1
    Last Post: 11-07-2006, 06:14 PM
  4. 4.0 RC1 Documents initialization failed on upgrade
    By neilmc in forum Administrators
    Replies: 13
    Last Post: 10-05-2006, 02:46 AM
  5. MTA is Dying after yum update
    By tonyawbrey in forum Administrators
    Replies: 27
    Last Post: 04-02-2006, 06:11 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •