Openvpn doesn't see password file?

Question

linux

In Mint 19, openvpn does not see the file for the auth-user-pass directive with login and password. In Mint 18 it worked without problems. Starting openvpn via sudo systemctl. 777 per file doesn't help.
In journalctl:

-- Начат процесс запуска юнита [email protected]
окт 02 17:14:41 PCM23 ovpn-client[30959]: WARNING: cannot stat file '<путь до файла который точно есть и доступен для чтения>': No such file or directory (errno=2)
окт 02 17:14:41 PCM23 ovpn-client[30959]: Options error: --auth-user-pass fails with 'путь до файла который точно есть и доступен для чтения': No such file or directory (errno=2)
окт 02 17:14:41 PCM23 ovpn-client[30959]: Options error: Please correct these errors.
окт 02 17:14:41 PCM23 ovpn-client[30959]: Use --help for more information.
окт 02 17:14:41 PCM23 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
окт 02 17:14:41 PCM23 systemd[1]: [email protected]: Failed with result 'exit-code'.
окт 02 17:14:41 PCM23 systemd[1]: Failed to start OpenVPN connection to client.
-- Subject: Ошибка юнита [email protected]
-- Defined-By: systemd

I also tried to add the cd directive near auth-user-pass with the path to the folder with the login and password file. Swears in the same way, but specifically on the path to cd.
vpn config:

client
dev tun
proto tcp-client
remote sphvpn.from.sh 443
resolv-retry infinite
cipher AES-256-CBC

keepalive 10 120

# Keys
# Identity
ca ca.crt
tls-auth ta.key 1
key-direction 1
remote-cert-tls server
cd /home/<пользователь>/openvpn
auth-user-pass openvpn.txt
auth-nocache

# Security
nobind
persist-key
persist-tun
comp-lzo
verb 3

# DNS
script-security 2
up ./update-resolv.sh
down ./update-resolv.s

/etc/defaults/openvpn:

AUTOSTART="all
STATUSREFRESH=10
OPTARGS=""
OMIT_SENDSIGS=0

UPD: I solved the problem by putting a file with a login\password near the vpn settings file in the /etc/openvpn/ directory

Answer 1

Check permissions on directories and files. And since you have openvpn running under systemd, I would check the access from the user under which it is run.