kopano server cannot write attachment folder

gmcpaul

hi thctlo,

thanks for the input
tried to disable apparmor… did not help…
i also wonder why it should have that issue just after upgrading the dep packages…

br,
paul

thctlo

@gmcpaul after upgrading packages.
Can you show me the /var/log/dpkg.log of last day or 2?
Of which packages upgraded and got removed?

And you “tried” to disable apparmor? so was it disabled of not because if you get an kernel upgrade, apparmor is most probely reinstalled.
Please verify it. i had and issue also and discovered apparmor running again.
for a complete remove, you need to adjust the boot lines for the kernel and remove the app itself.

gmcpaul

yes it forgot that apparmor integrates to the kernel sorry… i was thinking the service just needed to be disabled… sorry about that.
so i did now “systemctl disable apparmor” and rebooted the machine.
also added the apparmor=0 parameter to the grub boot file prior to the boot.
now aa-status:
apparmor filesystem is not mounted.

trying to reset the kopanos attachment path and restart the core service resulted in:
2020-08-12T16:35:57.605343: [=======] Starting kopano-server version 10.0.6 (pid 2538 uid 999)
2020-08-12T16:35:57.605351: [warning] Config warning: Option “server_ssl_protocols” has no effect anymore, and will be removed in a future release.
2020-08-12T16:35:57.605384: [info ] Using epoll events
2020-08-12T16:35:57.605571: [info ] Re-using fd 5 for 0.0.0.0:236
2020-08-12T16:35:57.605606: [info ] Re-using fd 6 for [::]:236
2020-08-12T16:35:57.607851: [info ] Re-using fd 7 for unix:/var/run/kopano/prio.sock
2020-08-12T16:35:57.607969: [info ] Re-using fd 10 for unix:/var/run/kopano/server.sock
2020-08-12T16:35:57.608032: [info ] Coredump status left at system default.
2020-08-12T16:35:57.608507: [error ] Unable to create attachment directory “/home/kopano/attachments”: Keine Berechtigung

apt Log is a bit long…cant post it here

gmcpaul

apt-log https://drive.google.com/file/d/1_WqopA5z0MIACqroVjmk0HVhKSbwLuTd/view?usp=sharing

gmcpaul

for me it looks if it is a bug or so, i cant believe that a simple dpkg upgrade will result in apparmor or file permission block/corruption, does it?
was using a daily build package tho

thctlo

hm, that log looks fine.
and we are sure apparmor is disabled

ah, but this shows : Option “server_ssl_protocols” has no effect anymore,

Your running with an old config.
i cant look in my kopano server atm but run :

updatedb
locate server.cfg
diff the version in /usr/share something and /etc/kopano

basily what i say here is, print out the old version of all config.
and use the new one to update the current config.
copy the one’s from //usr/share to /etc/kopano and edit these.

in this case.
“/home/kopano/attachments”: Keine Berechtigung

most probely, service starts as “SOME” users and rights are root there.
ls -al /home/kopano/attachments
shows which user?

gmcpaul

yes its strange
als tried the thing with config script before… did not help :/

ls -al /home/kopano/attachments

drwxrwx— 12 kopano kopano 4096 Aug 12 00:17 .
drwxrwx— 3 kopano kopano 4096 Dez 30 2016 …
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 0
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 1
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 2
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 3
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 4
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 5
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 6
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 7
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 8
drwxrwx— 22 kopano kopano 4096 Mai 16 2014 9

i tried to overwrite the settings with chown and chmod… didnt help either…

confused

thctlo

Verify the config files as i showed.
Thats first todo now.

gmcpaul

could not find anything special…

diff /etc/kopano/server.cfg /etc/kopano/server.cfg.dpkg-dist
22c22
< server_pipe_name = /var/run/kopano/server.sock

#server_pipe_name = /var/run/kopano/server.sock
28c28
< server_pipe_priority = /var/run/kopano/prio.sock

#server_pipe_priority = /var/run/kopano/prio.sock
45c45
< local_admin_users = root kopano fetchmail clamav vmail

local_admin_users = root kopano
52c52
< system_email_address = other@dot.com

system_email_address = postmaster@localhost
55c55
< run_as_user = kopano

#run_as_user = kopano
58c58
< run_as_group = kopano

#run_as_group = kopano
61c61
< pid_file = /var/run/kopano/server.pid

#pid_file = /var/run/kopano/server.pid
71c71
< coredump_enabled = systemdefault

#coredump_enabled = systemdefault
93c93
< log_level = 6

#log_level = 3
99c99
< log_buffer_size = 0

#log_buffer_size = 0
129c129
< mysql_user = kopano

mysql_user = root
132c132
< mysql_password = xxx

mysql_password =
159,160c159
< #attachment_path = /home/kopano/attachments
< attachment_path = /var/lib/kopano/attachments

attachment_path = /var/lib/kopano/attachments
201c200
< server_ssl_key_file = /etc/ssl/certs/ssl.pem

server_ssl_key_file = /etc/kopano/ssl/server.pem
204c203
< server_ssl_key_pass =

server_ssl_key_pass = replace-with-server-cert-password
207c206
< server_ssl_ca_file = /etc/ssl/certs/ssl.cer

server_ssl_ca_file = /etc/kopano/ssl/cacert.pem
214c213
< #server_ssl_protocols = !SSLv2

#server_ssl_protocols =
322c321
< quota_warn = 1000

quota_warn = 0
442c441
< disabled_features = pop3

disabled_features = imap pop3

gmcpaul

just to note: i also tried the /usr/share/man/man5/kopano-server.cfg.5.gz file with my parameters without success
same result :/

i have no idea why the attachment folder cant be written on /home ; specially when it was no problem with the version before

fbartels

@gmcpaul said in kopano server cannot write attachment folder:

just to note: i also tried the /usr/share/man/man5/kopano-server.cfg.5.gz file with my parameters without success

Yeah, comparing the cfg files was imho a deadend anyways. The only bit of information that could be gained from it is if you had used a completely different run_as_.

@gmcpaul said in kopano server cannot write attachment folder:

i also wonder why it should have that issue just after upgrading the dep packages…

Kopano is just using the filesystem provided by your os, so whatever now prevents the software from accessing this path must have come from either system updates, a changed system configuration or other external factors.

To verify this you could run sudo -u kopano touch /home/kopano/attachments/test. This will switch into the user context of the Kopano user and will want to create a file at the given path. This will already fail for you.

gmcpaul

hi felix,

thanks for your reply.

tried your suggestion … fails not O_o

root@srv01:/# sudo -u kopano touch /home/kopano/attachments/test
root@srv01:/# cd /home/kopano/attachments/
root@srv01:/home/kopano/attachments# ls
0 1 2 3 4 5 6 7 8 9 test

gmcpaul

even updated os to ubuntu 20.04 lts … just for “fun”
then reinstalled the latest nightly build, core-10.0.6.406.7ff4b4b-Ubuntu_20.04-amd64.tar.gz.

i checked if kopano-server is started as user kopano via ps and it did.
also tried to start the kopano-server by commenting the run-as parameters out of the server.cnf file.
the sudo -u kopano …touch test proofed that there is no problem with permissions for the homedir
apparmor was disabled

for me it looks like a bug … but are there any other tests i can make to find the problem?

thanks

fbartels

@gmcpaul which version were you using prior to your upgrade?

In case you can write to a path directly, but not when the running through systemd, then https://stash.kopano.io/projects/KC/repos/kopanocore/commits/f957fea2d774581d1150ca32e25e40c023140788#installer/linux/kopano-server.service could be the culprit.

gmcpaul

Hi @fbartels ,
According to the Logs it should have been 9.0.2.158.3dd898471-0+246.1.

my kopano-sever.service part :

[Service]
Type=simple
ExecStart=/usr/sbin/kopano-server
ExecReload=/bin/kill -HUP $MAINPID
TimeoutStopSec=60
ProtectSystem=full
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
PrivateTmp=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

gmcpaul

changing
ProtectHome=yes to no
then
systemctl daemon-reload
then
/etc/init.d/kopano-server restart

now seems good according to server.log :D

fbartels

@gmcpaul an update safe way would be to create an override file. First run
sudo systemctl edit kopano-server and in the resulting editor paste the following:

[Service]
ProtectHome=no

gmcpaul

@fbartels said in kopano server cannot write attachment folder:

[Service]
ProtectHome=no

@fbartels many thanks!!
have a nice weekend

case can be closed from my side.

longsleep

@gmcpaul said in kopano server cannot write attachment folder:

changing
ProtectHome=yes to no

This is less secure and cannot be recommended. It would be much better if your attachments were stored outside of /home and the setting is kept as is. See https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome= for exact details on the protection offfered when ProtectHome is enabled.

gmcpaul

Hi @longsleep
well thank you for the input.
I will keep in mind for future projects.
in my case the machine was historically (beginning from zarafa) set up with the use of /home to let large amounts of data outsourced on an seperate partition for a service to run in a “bubble” and to keep the files out of default system paths.
Since the filese are locked in run_as environments i thougt that wa a good design. Also when space is eaten up and you need to enlarge the hdd in a vm for example… so all was done in good intension so to speak.

Well… lessons learned for me :D
Thank you all

kopano server cannot write attachment folder

ls -al /home/kopano/attachments

diff /etc/kopano/server.cfg /etc/kopano/server.cfg.dpkg-dist 22c22 < server_pipe_name = /var/run/kopano/server.sock

diff /etc/kopano/server.cfg /etc/kopano/server.cfg.dpkg-dist
22c22
< server_pipe_name = /var/run/kopano/server.sock