Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Documents permissions messed up

  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

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

    Default

    Quote Originally Posted by Greg View Post
    The only place where it could be left is global config
    run
    zmprov> gcf zimbraNotebookAccount

    to see if it is there
    I did that in my previous post :-)

    Anyway, to humor you, I ran it again. It says wiki@... everywhere except in the client UI in the upper right corner.

    Even direct URL access works for the notebook (https://mydomain.com/home/wiki/Notebook), so I'm stumped.

    Is it possible that tomcat is caching it somewhere? My Firefox cache has been cleared several times, so I'm pretty sure that isn't it.

    Thanks,
    John

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

    Default

    Quote Originally Posted by jdell View Post
    I did that in my previous post :-)
    yep, sorry I was rereading your post now and found that
    Bugzilla - Wiki - Downloads - Before posting... Search!
    P.S.: don't forget to vote on this bug
    add Samba LDAP entries to Exchange Migration Tool

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

    Default

    Quote Originally Posted by jdell View Post
    I did that in my previous post :-)

    Anyway, to humor you, I ran it again. It says wiki@... everywhere except in the client UI in the upper right corner.

    Even direct URL access works for the notebook (https://mydomain.com/home/wiki/Notebook), so I'm stumped.

    Is it possible that tomcat is caching it somewhere? My Firefox cache has been cleared several times, so I'm pretty sure that isn't it.

    Thanks,
    John
    Alright, I know where it is coming from (I tried it on my dev box). This name is the name of the creator of the wiki folder. You created the domain-level wiki using account wiki2, so wiki2 is the creator. If you want to see wiki@domain.com in the upper-right corner in the mail client, you need to do two things:
    1) zmprov> md yourdomain.com zimbraNotebookAccount ""
    2) go to the admin UI and click "Create Documents" again, use wiki@yourdomain.com this time.

    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

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

    Default

    Quote Originally Posted by Greg View Post
    Alright, I know where it is coming from (I tried it on my dev box). This name is the name of the creator of the wiki folder. You created the domain-level wiki using account wiki2, so wiki2 is the creator. If you want to see wiki@domain.com in the upper-right corner in the mail client, you need to do two things:
    1) zmprov> md yourdomain.com zimbraNotebookAccount ""
    2) go to the admin UI and click "Create Documents" again, use wiki@yourdomain.com this time.

    Greg
    Ok, well that is what I tried back in post #5, but I kept getting the error that I couldn't use the 'wiki' account because it was already in use even though I had deleted the account.

    Anyway, I've already added some content to the Notebook because I need to get some info and downloads up there for users, so I can't nuke it again.

    If the only negative effect is the display of the wrong creator, I can live with that. If you can give me a hint of where that is coming from (LDAP or MySQL), I'll just manually go in a fix it, since it isn't hurting anything being wrong anyways.

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
  •