Handling uid and gid
Results 1 to 5 of 5

Thread: Handling uid and gid

  1. #1
    Member
    Join Date
    Dec 2013
    Posts
    33

    Handling uid and gid

    Hi,

    In a migration from foss 8.0.9 to ne 8.8.9, we are using a shared nfs.

    We mounted the nfs share on /nfs folder. Once mounted we created a folder named "migration" and chmod 0777 to it. The idea is to use it as a backup destiny and then import backups from during an incremental migration.

    The zimbra uid and gid are different between origin server and destiny servers. Is this going to be a problem? Any way to workaround this without having to change owner:group before every import and export to match the operation taking place?

    Thanks!

  2. #2
    Member
    Join Date
    Dec 2013
    Posts
    33

    update

    So far, I've seen that it would be problem and possible solutions (2 found in this forum on others from me), would be...from worst to best imho:
    5) backup -> change ownership -> restore -> change ownsershipe -> backup...and so on for an incremental migration.
    4) backup -> copy backup to new location -> change ownership in new location and so on for an incremental migration.
    3) change uid:gid in destination servers to match those from origin server.
    2) create a group in new server with the same gid as the zimbra group in the origin server. Add the zimbra user in the new server to the newly created group. (as far as I could see, read permission is granted to group for files created by zextras backup).
    1) add the anonuid and anongid options to the exports file (only applies when nfs is being used) on the nfs server serving the storage.

    Sadly, option 1 is not working for some reason. Our "nfs" server is a qnap and it is not reflecting the change even when we did reload configuration.

    We will try with number 2...crossing my fingers as starting from nš...is all tears and pain for me.

    Am I'm missing something? Any ideas or suggestions?


  3. #3
    Member
    Join Date
    Dec 2013
    Posts
    33
    Well,

    As option nš1 is not doable with the qnap storage in place, option nš2 was were I was helding my hopes. Sadly, ZeXtras checks for zimbra user specific read permission instead of just going ahead with the read permission inherited from the group for which zimbra now belongs (a manually created group to match the gid of the zimbra user in origin server).

    Operation requested by: zimbra

    Network Modules NG Version: 2.9.0
    commit: 423b5076c550c71168b23f8b8cc649363bea2d78

    Zal Version: 2.4.0
    Zal commit: 93807f76531868754de673a94725162b2b2a0edc
    Zimbra version: 8.8.9_GA_3019 20180809160254 20180809-1624 NETWORK

    - exception -
    com.zextras.lib.Error.UnableToReadDirectoryError: Missing read permission for zimbra user on path /tools/nfs/migracion/accounts
    at com.zextras.modules.backup.operations.ZEExternalRe storeOperation.checkBackupPermission (ZEExternalRestoreOperation.java:540)
    at com.zextras.modules.backup.operations.ZEExternalRe storeOperation.checkBackupPermission (ZEExternalRestoreOperation.java:550)
    at com.zextras.modules.backup.operations.ZEExternalRe storeOperation.doOperation (ZEExternalRestoreOperation.java:573)
    at com.zextras.lib.operations.ZEOperation.exec (ZEOperation.java:774)
    at com.zextras.lib.operations.LegacyOperationProxy.ex ec (LegacyOperationProxy.java:84)
    at com.zextras.lib.operations.ModifiableStatefulOpera tion.exec (ModifiableStatefulOperation.java:122)
    at com.zextras.lib.operations.OperationStarterActivit y.run (OperationStarterActivity.java:48)
    at com.zextras.lib.activities.ActivityThread.run (ActivityThread.java:138)

    Looks like I'll have to go for option nš3, which I'm not happy doing as it may lead to some unexpected behaviour with zimbra itself :/

  4. #4
    Active Member
    Join Date
    Oct 2018
    Posts
    7

    Solution

    After a lot of wasted time on forums etc. the only solution that you can rely on is to plan in advance properly and install the target server in advance with the correct user info.

    Start with a new clean server.
    Configure a new user zimbra and group zimbra with a UID:GID to match the source server.

    Mount the NFS share

    Install the new zimbra
    install the Zextras suite.
    Disable the backup scanner.
    Import the backup

    All should be well.

    Observation. Zimbra 8.8.9 on 16.04 is very slow compared to previous versions.

  5. #5
    Member
    Join Date
    Dec 2013
    Posts
    33
    Quote Originally Posted by Antonical View Post
    After a lot of wasted time on forums etc. the only solution that you can rely on is to plan in advance properly and install the target server in advance with the correct user info.

    Start with a new clean server.
    Configure a new user zimbra and group zimbra with a UID:GID to match the source server.

    Mount the NFS share

    Install the new zimbra
    install the Zextras suite.
    Disable the backup scanner.
    Import the backup

    All should be well.

    Observation. Zimbra 8.8.9 on 16.04 is very slow compared to previous versions.
    I'm not a big fan of doing that, but it is an alternative Finally the guy in charge of storage in the customer came back from vacation and managed to configure that appliance to use the anonuid and anongid...so migration proceed as planned.

    Thanks for your answer mate!

Bookmarks

Posting Permissions

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