Navigation

    Kopano
    • Register
    • Login
    • Search
    • Categories
    • Get Official Kopano Support
    • Recent
    Statement regarding the closure of the Kopano community forum and the end of the community edition

    Unable to bind to port 236

    Kopano Groupware Core
    3
    22
    6475
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • BMWfan
      BMWfan @fbartels last edited by BMWfan

      @fbartels thank you for your help. I made a change in the Server.cfg without to know and saved the config. Now i revert the cfg back and it works. Nevertheless, the failures

      Mon Jan 15 15:27:16 2018: [error  ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable sysctl to contain the value 2, not 0.
Mon Jan 15 15:27:52 2018: [error  ] Error while connecting to search on "file:///var/run/kopano/search.sock"

      still exists. Do you know, how i can fix this?

      fbartels 1 Reply Last reply Reply Quote 0
      • fbartels
        fbartels Kopano @BMWfan last edited by

        @bmwfan

        regarding “kopano-server requires the fs.suid_dumpable” https://www.rootusers.com/use-procsys-and-sysctl-to-modify-and-set-kernel-runtime-parameters/ should help.

        for the “Error while connecting to search” you should check if kopano-search is running and if its running if its currently busy creating you initial index.

        Regards Felix

        Resources:
        https://kopano.com/blog/how-to-get-kopano/
        https://documentation.kopano.io/
        https://kb.kopano.io/

        Support overview:
        https://kopano.com/support/

        BMWfan 1 Reply Last reply Reply Quote 0
        • BMWfan
          BMWfan @fbartels last edited by BMWfan

          @fbartels the kopano-search process is running

          â kopano-search.service - Kopano Core Search Engine
   Loaded: loaded (/lib/systemd/system/kopano-search.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-01-16 10:43:18 CET; 9min ago
     Docs: man:kopano-search(8)
           man:kopano-search.cfg(5)
 Main PID: 3685 (python2)
   CGroup: /system.slice/kopano-search.service
           ââ3685 python2 /usr/sbin/kopano-search -F
           ââ3689 python2 /usr/sbin/kopano-search -F

          but in the search.log are this errors:

          2018-01-16 10:53:24,132 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5)
2018-01-16 10:53:30,599 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5)
2018-01-16 10:53:37,066 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5)
2018-01-16 10:53:43,528 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5)
2018-01-16 10:53:49,989 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5)
2018-01-16 10:53:56,396 - index0 - ERROR - Too many retries, skipping change
2018-01-16 10:53:56,459 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=0/5)
2018-01-16 10:54:02,922 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5)
2018-01-16 10:54:09,394 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5)
2018-01-16 10:54:15,852 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5)
2018-01-16 10:54:22,308 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5)
2018-01-16 10:54:28,777 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5)

          I found with some researches a small explanation on https://kb.kopano.io/display/WIKI/MAPI+error+codes
          of the error code 0x80040115:

          MAPI_E_NETWORK_ERROR

          but this says me nothing.

          Ive seen in this forum entry that you ask in a nearly similar behaviour for this output:
          kopano-stats --top
          The red marked area shows the line which is comming and leaving and comming and leaving. All other lines stay the whole time.

          Also my spamd.log gives me nearly the same error:

            File "/usr/lib/python2.7/dist-packages/kopano/ics.py", line 104, in ImportMessageChange
    item.mapiobj = _utils.openentry_raw(mapistore, entryid.Value, 0)
  File "/usr/lib/python2.7/dist-packages/kopano/utils.py", line 74, in openentry_raw
    return _openentry_helper(mapistore, entryid, flags | MAPI_MODIFY)
  File "/usr/lib/python2.7/dist-packages/kopano/utils.py", line 68, in _openentry_helper
    return mapistore.OpenEntry(entryid, IID_IECMessageRaw, flags)
  File "/usr/lib/python2.7/dist-packages/MAPICore.py", line 605, in OpenEntry
    return _MAPICore.IMsgStore_OpenEntry(self, cbEntryID, lpInterface, ulFlags)
MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)

          Under the folder /var/run/kopano are these files:

          servername.dbf4700-10197  prio.sock  search.pid  search.pid.lock  server.pid  server.sock

          so it locks as the search service gets the false name. Do you know how i can change this?
          Is this a configuration which is changed between the the releases 8.4.90.1513_0+172 and 8.5.80.77_0+188 ?

          1 Reply Last reply Reply Quote 0
          • AnotherAndy
            AnotherAndy last edited by

            Hi,
            could you please show us your search.cfg ?

            BMWfan 1 Reply Last reply Reply Quote 0
            • BMWfan
              BMWfan @AnotherAndy last edited by BMWfan

              @anotherandy thaths my search.cfg

              ##############################################################
# INDEXED SEARCH SERVICE SETTINGS

# Location of the index files
index_path          =   /var/lib/kopano/search/

# run as specific user
#run_as_user         = kopano

# run as specific group
#run_as_group        = kopano

# control pid file
#pid_file            =   /var/run/kopano/search.pid

# run server in this path (when not using the -F switch)
#running_path = /var/lib/kopano

# Limit the number of results returned (0 = don't limit)
limit_results		=	1000

##############################################################
# CONNECTION TO STORAGE SERVER SETTINGS
#

# Socket to find the connection to the storage server.
# Use https to reach servers over the network
#server_socket = file:///var/run/kopano/server.sock

# Login to the storage server using this SSL Key
#sslkey_file         = /etc/kopano/ssl/search.pem

# The password of the SSL Key
#sslkey_pass         = replace-with-server-cert-password

##############################################################
# LISTEN SETTINGS
#

# binding address
# To setup for multi-server, use: http://0.0.0.0:port or https://0.0.0.0:port
server_bind_name   =   file:///var/run/kopano/search.sock

# File with RSA key for SSL, used then server_bind_name uses https
ssl_private_key_file = /etc/kopano/search/privkey.pem

# File with certificate for SSL, used then server_bind_name uses https
ssl_certificate_file = /etc/kopano/search/cert.pem

##############################################################
# LOG SETTINGS

# Logging method (syslog, file)
log_method          =   file

# Loglevel (0(none), 1(crit), 2(err), 3(warn), 4(notice), 5(info), 6(debug))
#log_level           =   3

# Logfile for log_method = file, use '-' for stderr
log_file            =   /var/log/kopano/search.log

# Log timestamp - prefix each log line with timestamp in 'file' logging mode
log_timestamp       =   1


##############################################################
# ADVANCED INDEXED SEARCH SETTINGS

# Back end search engine (currently only xapian is supported)
#search_engine = xapian

# Size of indexing cache (used for indexing only, not for searching)
term_cache_size		=   64M

# Ignore properties upon indexing
# Only override this setting to expand the list
#index_exclude_properties = 007D 0064 0C1E 0075 678E 678F

# Number of indexing processes used during initial indexing
# Setting this to a higher value can greatly speed up initial indexing,
# especially when attachments are indexed.
index_processes		=   1

# Index drafts folder
#index_drafts = yes

# Index junk folder
#index_junk = yes

# Prepare search suggestions ("did-you-mean?") during indexing
# This takes up a large percentage of the used disk space
#suggestions = yes

##############################################################
# ATTACHMENT INDEX SETTINGS

# Should attachments be indexed
index_attachments	= no

# Maximum file size for attachments
index_attachment_max_size = 5M

              Can i see anywhere a default server.cfg without to install it on a server, then i could compare it with mine?

              fbartels 1 Reply Last reply Reply Quote 0
              • fbartels
                fbartels Kopano @BMWfan last edited by

                @bmwfan you can find the default server.cfg in /usr/share/doc/kopano/example-config

                Regards Felix

                Resources:
                https://kopano.com/blog/how-to-get-kopano/
                https://documentation.kopano.io/
                https://kb.kopano.io/

                Support overview:
                https://kopano.com/support/

                BMWfan 1 Reply Last reply Reply Quote 0
                • BMWfan
                  BMWfan @fbartels last edited by BMWfan

                  @fbartels thank you. I’ve compared it but there is no difference at the search_socket in server.cfg.

                  Had anyone another idea?

                  1 Reply Last reply Reply Quote 0
                  • AnotherAndy
                    AnotherAndy last edited by

                    Hi, have you checked the file system permissions?
                    an what says
                    #netstat -taupen - is maybe another “zombie” blocking port 236?

                    BMWfan 1 Reply Last reply Reply Quote 0
                    • BMWfan
                      BMWfan @AnotherAndy last edited by BMWfan

                      @anotherandy only the kopano-server is binded to the port 236

                      Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          88914202   624/master
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      0          88913099   347/slapd
tcp        0      0 127.0.0.1:2501          0.0.0.0:*               LISTEN      0          88911860   260/perl
tcp        0      0 127.0.0.1:10024         0.0.0.0:*               LISTEN      113        88914619   635/amavisd-new (ma
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN      0          88914341   624/master
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      109        88913829   484/mysqld
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      102        88912615   276/systemd-resolve
tcp        0      0 0.0.0.0:236             0.0.0.0:*               LISTEN      0          89006970   736/kopano-server
tcp        0      0 85.25.192.248:80        118.185.246.237:15354   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:62374   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:28077   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:28453   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:2433    SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:5735    SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:24878   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:59915   SYN_RECV    0          0          -
tcp        0      0 85.25.192.248:80        118.185.246.237:4121    SYN_RECV    0          0          -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          88912901   301/sshd
tcp        0      0 85.25.192.248:22        47.186.75.15:46731      ESTABLISHED 0          91557796   8125/sshd: root [pr
tcp        0      0 127.0.0.1:389           127.0.0.1:37400         ESTABLISHED 110        89147103   347/slapd
tcp        0      0 85.25.192.248:22        178.249.80.48:56795     ESTABLISHED 0          91548127   8064/sshd: root@not
tcp        0      0 127.0.0.1:34418         127.0.0.1:389           ESTABLISHED 999        89008115   736/kopano-server
tcp        0      0 127.0.0.1:34416         127.0.0.1:389           ESTABLISHED 999        89008113   736/kopano-server
tcp        0      0 127.0.0.1:34424         127.0.0.1:389           ESTABLISHED 999        89008837   736/kopano-server
tcp        0      0 127.0.0.1:389           127.0.0.1:34414         ESTABLISHED 110        89008112   347/slapd
tcp        0     52 85.25.192.248:22        178.249.80.48:56851     ESTABLISHED 0          91556526   8110/sshd: root@pts
tcp        0      0 127.0.0.1:389           127.0.0.1:34416         ESTABLISHED 110        89008114   347/slapd
tcp        0      0 127.0.0.1:389           127.0.0.1:34420         ESTABLISHED 110        89008503   347/slapd
tcp        0      0 85.25.192.248:22        178.249.80.48:52766     ESTABLISHED 0          88915113   652/sshd: root@nott
tcp        0      0 127.0.0.1:389           127.0.0.1:34424         ESTABLISHED 110        89008838   347/slapd
tcp        0      0 127.0.0.1:34412         127.0.0.1:389           ESTABLISHED 999        89008103   736/kopano-server
tcp        0      0 127.0.0.1:34420         127.0.0.1:389           ESTABLISHED 999        89008502   736/kopano-server
tcp        0      0 127.0.0.1:389           127.0.0.1:34418         ESTABLISHED 110        89008116   347/slapd
tcp        0      0 127.0.0.1:37400         127.0.0.1:389           ESTABLISHED 999        89147102   736/kopano-server
tcp        0      0 127.0.0.1:389           127.0.0.1:37408         ESTABLISHED 110        89147243   347/slapd
tcp        0      0 85.25.192.248:22        178.249.80.48:52933     ESTABLISHED 0          89003191   675/sshd: root@pts/
tcp        0      0 85.25.192.248:22        178.249.80.48:55793     ESTABLISHED 0          90831492   5567/sshd: root@not
tcp        0      0 127.0.0.1:389           127.0.0.1:34412         ESTABLISHED 110        89008104   347/slapd
tcp        0      0 127.0.0.1:37408         127.0.0.1:389           ESTABLISHED 999        89147242   736/kopano-server
tcp        0      0 127.0.0.1:34414         127.0.0.1:389           ESTABLISHED 999        89008111   736/kopano-server
tcp6       0      0 :::25                   :::*                    LISTEN      0          88914203   624/master
tcp6       0      0 :::389                  :::*                    LISTEN      0          88913100   347/slapd
tcp6       0      0 ::1:10024               :::*                    LISTEN      113        88914620   635/amavisd-new (ma
tcp6       0      0 :::5355                 :::*                    LISTEN      102        88912618   276/systemd-resolve
tcp6       0      0 :::80                   :::*                    LISTEN      0          89517296   2944/apache2
tcp6       0      0 :::2003                 :::*                    LISTEN      0          89014987   833/kopano-dagent
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           102        88912614   276/systemd-resolve
udp        0      0 127.0.0.53:53           0.0.0.0:*                           102        88912613   276/systemd-resolve
udp6       0      0 :::5355                 :::*                                102        88912617   276/systemd-resolve

                      Permissions to which folder exactly?

                      I’am not sure if its depending on permissions. The server.cfg reference to the file:///var/run/kopano/search.sock but there is now one with exactly this name:

                      dagent.pid  servername.3411a700-3967  prio.sock  search.pid  search.pid.lock  server.pid  server.sock
                      1 Reply Last reply Reply Quote 0
                      • AnotherAndy
                        AnotherAndy last edited by

                        It looks like the search is not starting correct.
                        What shows the search.log ?

                        BMWfan 1 Reply Last reply Reply Quote 0
                        • BMWfan
                          BMWfan @AnotherAndy last edited by

                          @anotherandy in the 5th post you can see the asked output.

                          1 Reply Last reply Reply Quote 0
                          • AnotherAndy
                            AnotherAndy last edited by

                            ok - the folder /var/lib/kopano/search/ belongs to the user kopano?
                            also /var/lib/kopano ?

                            have you tried to clean the folder and restart the search? If you have vmware snapshot the vm before doing this.
                            And - sounds stupid, but did you reboot the machine?

                            BMWfan 1 Reply Last reply Reply Quote 0
                            • BMWfan
                              BMWfan @AnotherAndy last edited by BMWfan

                              @anotherandy thank you, the permissions are the same. The group and the owner is kopano (755).
                              I’ve cleaned the search folder and rebooted the machine with no result.

                              I`ve changed now the search log level to 6 (debug). Many index entrys are running over the screen until these entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000. When these entryid is there then the MAPI Errors begins.

                              2018-01-22 19:49:25,920 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F4501000000050000005AA0C047B2434A8C8D710000D392503600000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402783A01000000, docid 126306
2018-01-22 19:49:25,952 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F4501000000050000001C00CC2D3E314C3C95C7F592B26F485900000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402743A01000000, docid 126297
2018-01-22 19:49:25,979 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:25,993 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=0/5)
2018-01-22 19:49:26,448 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:26,456 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5)
2018-01-22 19:49:27,304 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:27,313 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5)
2018-01-22 19:49:28,971 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:28,980 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5)
2018-01-22 19:49:32,230 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:32,238 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5)
2018-01-22 19:49:38,688 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228
2018-01-22 19:49:38,696 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5)
2018-01-22 19:49:45,102 - index0 - ERROR - Too many retries, skipping change

                              Ive searched the entryid in the whole log and found these message:

                              2018-01-22 19:29:06,669 - index0 - ERROR - could not process change for entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000 ([SPropValue(0x65E00102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02R:\x01\x00\x00\x00'), SPropValue(0x30080040, 2017/02/03 20:07:12 GMT), SPropValue(0x65E20102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\xdez\x03\x00'), SPropValue(0x65E10102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\x02\x01\x00\x00\x00\x00'), SPropValue(0x65E30102, '\x14\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\xdez\x03\x00'), SPropValue(0x0FFF0102, '\x00\x00\x00\x00\xa4\x97u>{\x1bL\xe3\x89K\xb0j\xbb|\x1fE\x01\x00\x00\x00\x05\x00\x00\x00\xa8<\x94r\xb9\xd0F\xe6\xb8\x9f\xe5\x7f4\xda\x9b8\x00\x00\x00\x00'), SPropValue(0x67AA000B, False), SPropValue(0x0E070003, 3L), SPropValue(0x0FFA0102, '\xa4\x97u>{\x1bL\xe3\x89K\xb0j\xbb|\x1fE'), SPropValue(0x67110003, 126228L), SPropValue(0x67150003, 203L)]):

                              What kind of index is this and how can i fix this?

                              I thought i could reindex easily my user and then should the error go away, but also this is not functioning:

                              kopano-search --reindex=MyUser
Traceback (most recent call last):
  File "/usr/sbin/kopano-search", line 7, in <module>
    sys.exit(kopano_search.main())
  File "/usr/lib/python2.7/dist-packages/kopano_search/__init__.py", line 419, in main
    service.reindex()
  File "/usr/lib/python2.7/dist-packages/kopano_search/__init__.py", line 406, in reindex
    with closing(kopano.client_socket(self.config['server_bind_name'], ssl_cert=self.config['ssl_certificate_file'])) as s:
  File "/usr/lib/python2.7/dist-packages/kopano/service.py", line 266, in client_socket
    s.connect(addr2)
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 2] No such file or directory

                              @fbartels have you perhaps any idea?

                              1 Reply Last reply Reply Quote 0
                              • BMWfan
                                BMWfan last edited by

                                Can nobody help me or has further tips?

                                1 Reply Last reply Reply Quote 0
                                • AnotherAndy
                                  AnotherAndy last edited by

                                  I’m sorry no other idea from here.
                                  Maybe on sunday afternoon ~ 3 p.m. we can chat and try to find a solution together?

                                  BMWfan 1 Reply Last reply Reply Quote 0
                                  • BMWfan
                                    BMWfan @AnotherAndy last edited by

                                    @anotherandy thank you. This would be really cool.

                                    1 Reply Last reply Reply Quote 0
                                    • BMWfan
                                      BMWfan last edited by

                                      Today i had a chat with AnotherAndy which gaves me some tips. @AnotherAndy Thanks for that
                                      I would update now here the “diary” perhaps someone had then further ideas.

                                      In my server log are these entries:

                                      Sun Feb  4 15:55:16 2018: [error  ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory
Sun Feb  4 15:55:16 2018: [error  ] SerializeObject failed with error code 0x80000002 for object 24020
Sun Feb  4 15:55:22 2018: [error  ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory
Sun Feb  4 15:55:22 2018: [error  ] SerializeObject failed with error code 0x80000002 for object 24020
Sun Feb  4 15:55:29 2018: [error  ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory
Sun Feb  4 15:55:29 2018: [error  ] SerializeObject failed with error code 0x80000002 for object 24020
Sun Feb  4 15:55:35 2018: [error  ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory
Sun Feb  4 15:55:35 2018: [error  ] SerializeObject failed with error code 0x80000002 for object 24020
Sun Feb  4 15:55:42 2018: [error  ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory
Sun Feb  4 15:55:42 2018: [error  ] SerializeObject failed with error code 0x80000002 for object 2402

                                      Perhaps the MAPI Service is searching for that?

                                      In the time when iam overtaking the database and attachments from my old zarafa installation to the new Kopano installation there was no file under /var/lib/zarafa/attachments/2/16/ which is called 1762.gz .
                                      Is there a way to find the dependencies between the attachments and MAPI and delete this in the database?

                                      Best Regards

                                      Daniel

                                      fbartels 1 Reply Last reply Reply Quote 0
                                      • fbartels
                                        fbartels Kopano @BMWfan last edited by

                                        Hi @bmwfan ,

                                        since you know the filename, which includes the instanceid you could look up the hierarchyid of the attachment in the singleinstances table in the database. Based on the hierarchyid you can then identify the mapi object the attachment belongs to in the properties table. But you should not delete it directly from the database, instead you should then locate the email with e.g. WebApp and delete the message from there.

                                        An alternative and easier approach is to just create an empty gz archive with the name the server wants to lookup.

                                        Regards Felix

                                        Resources:
                                        https://kopano.com/blog/how-to-get-kopano/
                                        https://documentation.kopano.io/
                                        https://kb.kopano.io/

                                        Support overview:
                                        https://kopano.com/support/

                                        1 Reply Last reply Reply Quote 0
                                        • BMWfan
                                          BMWfan last edited by

                                          Thank you @fbartels.
                                          How can i identify in the webapp which mails belongs to the not available attachments?

                                          Regards

                                          Daniel

                                          fbartels 1 Reply Last reply Reply Quote 0
                                          • fbartels
                                            fbartels Kopano @BMWfan last edited by

                                            @bmwfan said in Unable to bind to port 236:

                                            How can i identify in the webapp which mails belongs to the not available attachments?

                                            By using search? From the properties table you will learn details such as subject, recipients/sender, body etc.

                                            Regards Felix

                                            Resources:
                                            https://kopano.com/blog/how-to-get-kopano/
                                            https://documentation.kopano.io/
                                            https://kb.kopano.io/

                                            Support overview:
                                            https://kopano.com/support/

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post