The compose plugin did not destroy portainer. You never set a proper data directory for portainer is my guess.
Do you still have your old version of portainer installed? (Even if it is not working)
The compose plugin did not destroy portainer. You never set a proper data directory for portainer is my guess.
Do you still have your old version of portainer installed? (Even if it is not working)
To solve the Portainer issue you can follow these steps. https://wiki.omv-extras.org/do…openmediavault-compose_67
As for the quick setup guide you followed, I assume you read the beginning of the guide and the conditions for using it. If you are doing this installation on an already configured server, this guide will serve as a reference but you should follow this: https://wiki.omv-extras.org/doku.php?id=omv6:docker_in_omv
Thanks for the quick responses.
ZitatYou never set a proper data directory for portainer is my guess.
Unfortunately, that's my guess, as well
Zitat
Do you still have your old version of portainer installed? (Even if it is not working)
How would I find this out? I cannot see it anymore in the OMV plugins. Portainer GUI is not reachable anymore (this is how I noticed it at all). A docker container ls does not list portainer or any of the containers that I had before the installation of openmediavault-compose. Btw I'm on 6.9.12-2 (Shaitan).
Zitat
To solve the Portainer issue you can follow these steps. https://wiki.omv-extras.org/do…openmediavault-compose_67
I can't, because as I wrote above, the portainer data directory either never existed or is gone now.
ZitatAs for the quick setup guide you followed, I assume you read the beginning of the guide and the conditions for using it. If you are doing this installation on an already configured server, this guide will serve as a reference but you should follow this: https://wiki.omv-extras.org/doku.php?id=omv6:docker_in_omv
I'm not sure how this should help? The NPM and the failban containers are up and running. NPM is having a Letsencrypt issue though, as I described above. This is the one I cannot solve
So from my perspective I can either try to "go backward" (reviving Portainer somehow) or to "go forward" (solving the NPM/Letsencrypt issue). And both directions seem blocked...
I can't, because as I wrote above, the portainer data directory either never existed or is gone now.
If you had Portainer running there was a data folder. I don't know if you have subsequently done anything that could have deleted that folder. If you have deleted that folder it will be difficult to recover Portainer. I would go ahead with configuring containers in the plugin and forgetting about Portainer.
I'm not sure how this should help? The NPM and the failban containers are up and running. NPM is having a Letsencrypt issue though, as I described above. This is the one I cannot solve
It's hard to know what's going wrong without seeing your server. That's why I suggested following that guide and basically checking folder paths and permissions, it is the most common failure.
Nextcloud AIO works with NPM and let's encrypt, I can attest to that.
OK, he had we'll say... "a series of unfortunate events"
Where he stands now...
Docker is back up and running with his old configs and containers, so portainer, plex, swag, etc.. are good.
NC is running, but he's getting some errors. Initially it was because he was still on like version 25. So we upgraded to 26, now he's getting some new errors. Unfortunately I'm out of time and am going to be busy probably until at least Wed night.. So if he wants to give you guys a chance to tackle this and post the errors he has, that's where he is, otherwise, I'm gonna hook up again with him probably Wed or Thur night and see if we can't figure out what is wrong with NC. and then clean up a few other things.
For now, I'd probably suggest he stay on Portainer till the NC issue is sorted out (as he's several versions behind anyway),
Thanks again KM0201 for all the great support
This is the current error message of the nextcloud container:
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] Connection refused in /config/www/nextcloud/lib/private/DB/Connection.php:142
Stack trace:
#0 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1531): OC\DB\Connection->connect()
#1 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1029): Doctrine\DBAL\Connection->getWrappedConnection()
#2 /config/www/nextcloud/lib/private/DB/Connection.php(264): Doctrine\DBAL\Connection->executeQuery()
#3 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(345): OC\DB\Connection->executeQuery()
#4 /config/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(280): Doctrine\DBAL\Query\QueryBuilder->execute()
#5 /config/www/nextcloud/lib/private/AppConfig.php(418): OC\DB\QueryBuilder\QueryBuilder->execute()
#6 /config/www/nextcloud/lib/private/AppConfig.php(184): OC\AppConfig->loadConfigValues()
#7 /config/www/nextcloud/lib/private/AppConfig.php(374): OC\AppConfig->getApps()
#8 /config/www/nextcloud/lib/private/legacy/OC_App.php(976): OC\AppConfig->getValues()
#9 /config/www/nextcloud/lib/private/Server.php(729): OC_App::getAppVersions()
#10 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\Server->OC\{closure}()
#11 /config/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#12 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(138): Pimple\Container->offsetGet()
#13 /config/www/nextcloud/lib/private/ServerContainer.php(171): OC\AppFramework\Utility\SimpleContainer->query()
#14 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(65): OC\ServerContainer->query()
#15 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(193): OC\AppFramework\Utility\SimpleContainer->get()
#16 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#17 /config/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#18 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(138): Pimple\Container->offsetGet()
#19 /config/www/nextcloud/lib/private/ServerContainer.php(171): OC\AppFramework\Utility\SimpleContainer->query()
#20 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(65): OC\ServerContainer->query()
#21 /config/www/nextcloud/lib/private/Server.php(1110): OC\AppFramework\Utility\SimpleContainer->get()
#22 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\Server->OC\{closure}()
#23 /config/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#24 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(138): Pimple\Container->offsetGet()
#25 /config/www/nextcloud/lib/private/ServerContainer.php(171): OC\AppFramework\Utility\SimpleContainer->query()
#26 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(65): OC\ServerContainer->query()
#27 /config/www/nextcloud/lib/private/Server.php(2065): OC\AppFramework\Utility\SimpleContainer->get()
#28 /config/www/nextcloud/lib/private/Files/View.php(119): OC\Server->getLockingProvider()
#29 /config/www/nextcloud/lib/private/Server.php(464): OC\Files\View->__construct()
#30 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\Server->OC\{closure}()
#31 /config/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#32 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(138): Pimple\Container->offsetGet()
#33 /config/www/nextcloud/lib/private/ServerContainer.php(171): OC\AppFramework\Utility\SimpleContainer->query()
#34 /config/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(65): OC\ServerContainer->query()
#35 /config/www/nextcloud/lib/private/Server.php(1467): OC\AppFramework\Utility\SimpleContainer->get()
#36 /config/www/nextcloud/lib/base.php(623): OC\Server->boot()
#37 /config/www/nextcloud/lib/base.php(1165): OC::init()
#38 /config/www/nextcloud/cron.php(43): require_once('...')
#39 {main}
Alles anzeigen
And the mariadb container keeps writing:
240123 12:06:28 mysqld_safe Logging to '/config/databases/b3506031d05d.err'.
240123 12:06:28 mysqld_safe Starting mariadbd daemon with databases from /config/databases
Any ideas?
config/databases/b3506031d05d.err says:
240123 19:21:45 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
240123 19:21:46 mysqld_safe Starting mariadbd daemon with databases from /config/databases
2024-01-23 19:21:46 0 [Note] /usr/bin/mariadbd (mysqld 10.5.13-MariaDB-log) starting as process 7028 ...
2024-01-23 19:21:46 0 [Note] InnoDB: Uses event mutexes
2024-01-23 19:21:46 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-01-23 19:21:46 0 [Note] InnoDB: Number of pools: 1
2024-01-23 19:21:46 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2024-01-23 19:21:46 0 [ERROR] mariadbd: Can't create/write to file '/var/tmp/ibXXXXXX' (Errcode: 13 "Permission denied")
2024-01-23 19:21:46 0 [ERROR] InnoDB: Unable to create temporary file; errno: 13
2024-01-23 19:21:46 0 [ERROR] mariadbd: Can't create/write to file '/var/tmp/ibXXXXXX' (Errcode: 13 "Permission denied")
2024-01-23 19:21:46 0 [ERROR] InnoDB: Unable to create temporary file; errno: 13
2024-01-23 19:21:46 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2024-01-23 19:21:46 0 [Note] InnoDB: Starting shutdown...
2024-01-23 19:21:46 0 [ERROR] Plugin 'InnoDB' init function returned error.
2024-01-23 19:21:46 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2024-01-23 19:21:46 0 [Note] Plugin 'FEEDBACK' is disabled.
2024-01-23 19:21:46 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2024-01-23 19:21:46 0 [ERROR] Aborting
Alles anzeigen
and repeats this every second.
What I'm asking myself is how is this
even possible? That's a directory within the container, right? How can it not have permissions inside the container?
I can go inside the container and execute chmod 777 /var/tmp and the container will start successfully (at least until the next deployment). But NC keeps showing me 404
So after bare-metal restart, the mariadb container is starting successfully. All containers (nextcloud, mariadb, swag & redis) are now running fine according to the container logs, but the front end still gives me 404. What am I missing?
So there was no way to update this container properly. Nobody knows why
I deployed a new stack in portainer with the containers nextcloud1, nextclouddb1 and redis1. Nextcloud was running locally on port 451 and with the help of KM0201 we managed to transfer the user data from the old data directory to the new one.
Next step was to make it reachable from the internet again by using swag (generally, following this guide). As I already had a nextcloud stack and a Swag stack, I applied the following steps:
Situation now: domain gives ERR_CONNECTION_REFUSED from inside the network, 502 from outside. https://192.168.0.101:451/, which worked before, also gives ERR_CONNECTION_REFUSED and overwrites the IP with my domain. https://<MY_DOMAIN>.duckdns.org/ shows the SWAG park page, but with invalid certificate.
Also, by accident, I started the old nextcloud stack once. Nextcloud didn't come up, but mariadb and redis. Hope that didn't break anything. I removed them immediately after realizing.
Somehow I've got the feeling that I would need to assign port 444 to 451 somewhere inside of swag. I already tried to set
ports:
- 444:451
(instead of 444:443) in the swag stack, but it didn't change anything.
You can find the config that I changed and the complete portainer stacks attached.
I hope I just have a silly mistake somewhere and someone here can spot it and point me towards it. I will be offline from now on till at least Sunday night. Maybe someone has some spare time over the weekend? Thanks
Can you post:
1. We didn't get to routing it through swag before I went to bed, but can you provide a screenshot of your router port forward settings (i thought on the last one you left it at default 443/80... that swag compose shows otherwise). EDIT: Nevermind, I see you addressed this.
2. nextcloud.subdomain.conf
Yes we left it on 443 but I adapted it to the guide because I thought there must be a reason for these ports.
2.
## Version 2021/05/18
# make sure that your dns has a cname set for nextcloud
# assuming this container is called "swag", edit your nextcloud container's config
# located at /config/www/nextcloud/config/config.php and add the following lines before the ");":
# 'trusted_proxies' => ['swag'],
# 'overwrite.cli.url' => 'https://nextcloud.your-domain.com/',
# 'overwritehost' => 'nextcloud.your-domain.com',
# 'overwriteprotocol' => 'https',
#
# Also don't forget to add your domain name to the trusted domains array. It should look somewhat like this:
# array (
# 0 => '192.168.0.1:444', # This line may look different on your setup, don't modify it.
# 1 => 'nextcloud.your-domain.com',
# ),
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name nextcloud.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app nextcloud;
set $upstream_port 443;
set $upstream_proto https;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
proxy_max_temp_file_size 2048m;
}
}
Alles anzeigen
This could be it, it's still on 443. But I don't have time to try now...
Alles anzeigenSo there was no way to update this container properly. Nobody knows why
I deployed a new stack in portainer with the containers nextcloud1, nextclouddb1 and redis1. Nextcloud was running locally on port 451 and with the help of KM0201 we managed to transfer the user data from the old data directory to the new one.
Next step was to make it reachable from the internet again by using swag (generally, following this guide). As I already had a nextcloud stack and a Swag stack, I applied the following steps:
- In my router I forwarded port 80 external to 82 internal and 443 external to 444 internal (it was 443 to 443 before)
- In the swag stack for the swag container I added under environment
- DOCKER_MODS=linuxserver/mods:swag-dashboard and under ports: - 444:443- 82:80 - 81:81 and redeployed the stack- checked that in /etc/appdata/swag/nginx/proxy-confs there is an nextcloud.subdomain.conf (without .sample). It was like this already and I didn't change anything
- adapted /etc/appdata/nextcloud1/config/www/nextcloud/config/config.php
- Uncommented the ##network modes in the nextcloud1 stack and redeployed
Situation now: domain gives ERR_CONNECTION_REFUSED from inside the network, 502 from outside. https://192.168.0.101:451/, which worked before, also gives ERR_CONNECTION_REFUSED and overwrites the IP with my domain. https://<MY_DOMAIN>.duckdns.org/ shows the SWAG park page, but with invalid certificate.
Also, by accident, I started the old nextcloud stack once. Nextcloud didn't come up, but mariadb and redis. Hope that didn't break anything. I removed them immediately after realizing.
Somehow I've got the feeling that I would need to assign port 444 to 451 somewhere inside of swag. I already tried to set
ports:
- 444:451
(instead of 444:443) in the swag stack, but it didn't change anything.
You can find the config that I changed and the complete portainer stacks attached.
I hope I just have a silly mistake somewhere and someone here can spot it and point me towards it. I will be offline from now on till at least Sunday night. Maybe someone has some spare time over the weekend? Thanks
No, the reason it's no longer working is it's forwarding through your domain again from the looks of it, and your domain is not set correctly.
/etc/appdata/nextcloud1/config/www/nextcloud/config/config.php
<?php
$CONFIG = array (
'datadirectory' => '/data',
'instanceid' => 'ocws1d9utfc2',
'passwordsalt' => <ANONYMIZED>,
'secret' => <ANONYMIZED>,
'trusteddomains' =>
array (
0 => '192.168.0.101:451',
1 => 'nextcloud.<ANONYMIZED>.duckdns.org',
),
'dbtype' => 'mysql',
'version' => '28.0.1.1',
'overwrite.cli.url' => 'https://nextcloud/.<ANONYMIZED>.duckdns.org',
'overwritehost' => 'nextcloud.<ANONYMIZED>.duckdns.org',
'overwriteprotocol' => 'https',
'dbname' => 'nextcloud1',
'dbhost' => 'nextclouddb1',
'dbport' => '',
'dbtableprefix' => 'oc',
'mysql.utf8mb4' => true,
'dbuser' => 'oc_nextcloud-adm',
'dbpassword' => <ANONYMIZED>,
'installed' => true,
'memcache.local' => '\OC\Memcache\APCu',
'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\APCu',
'upgrade.disable-web' => true,
);
Alles anzeigen
Note line 16. you have an extra / in there after "nextcloud"
change that to
and restart the container. If it still doesn't work, to regain local acess... change that line to:
and restart the container.
That will restore local access.
## Version 2021/05/18
# make sure that your dns has a cname set for nextcloud
# assuming this container is called "swag", edit your nextcloud container's config
# located at /config/www/nextcloud/config/config.php and add the following lines before the ");":
# 'trusted_proxies' => ['swag'],
# 'overwrite.cli.url' => 'https://nextcloud.your-domain.com/',
# 'overwritehost' => 'nextcloud.your-domain.com',
# 'overwriteprotocol' => 'https',
#
# Also don't forget to add your domain name to the trusted domains array. It should look somewhat like this:
# array (
# 0 => '192.168.0.1:444', # This line may look different on your setup, don't modify it.
# 1 => 'nextcloud.your-domain.com',
# ),
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name nextcloud.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app nextcloud;
set $upstream_port 443;
set $upstream_proto https;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
proxy_max_temp_file_size 2048m;
}
}
Alles anzeigen
Line 29. Change that to nextcloud1
Then save and restart swag.
We can easily change the names and what not back to nextcloud.. i just didn't want to nuke your old nextcloud install until I knew we had all your data imported into the new install (still not sure why the old one wouldn't upgrade at all)... so the easy button fix was to just add a "1" to everything.
If you've got all your data imported into the new nextcloud install, you can delete the old NC containers and the old stack you had.
ZitatNote line 16. you have an extra / in there after "nextcloud"
This wasn't real – something went wrong when I replaced the domain by <ANONYMIZED>. The line actually already looks like this:
In nextcloud.subdomain.conf I changed "set $upstream_app nextcloud;" to set $upstream_app nextcloud1; and restarted both the nextcloud1 and the swag container. The result was that NC is available again under https://192.168.0.101:451/ (but insecure and not replacing the URL), but not under the domain.
Also, I noticed that the old NC config.php was much more comprehensive, so I added a few sections from the old to the new config (redis config, trusted_proxies and mail config). Now it looks like this:
<?php
$CONFIG = array (
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => 'redis',
'port' => 6379,
),
'datadirectory' => '/data',
'instanceid' => 'ocws1d9utfc2',
'passwordsalt' => '<ANONYMIZED>',
'secret' => '<ANONYMIZED>',
'trusted_domains' =>
array (
0 => '192.168.0.101:451',
1 => 'nextcloud.<ANONYMIZED>.duckdns.org',
),
'dbtype' => 'mysql',
'version' => '28.0.1.1',
'overwrite.cli.url' => 'https://nextcloud.<ANONYMIZED>.duckdns.org',
'overwritehost' => 'nextcloud.<ANONYMIZED>.duckdns.org',
'overwriteprotocol' => 'https',
'dbname' => 'nextcloud1',
'dbhost' => 'nextclouddb1',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => 'oc_nextcloud-adm',
'dbpassword' => '<ANONYMIZED>',
'installed' => true,
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => true,
'memcache.locking' => '\\OC\\Memcache\\APCu',
'upgrade.disable-web' => true,
'default_phone_region' => 'COUNTRY_CODE',
'trusted_proxies' =>
array (
0 => '192.168.0.101:451',
1 => 'nextcloud.<ANONYMIZED>.duckdns.org',
),
'mail_smtpmode' => 'smtp',
'mail_smtpsecure' => 'tls',
'mail_sendmailmode' => 'smtp',
'mail_smtphost' => '<ANONYMIZED>',
'mail_smtpport' => '<ANONYMIZED>',
'mail_smtpauth' => 1,
'mail_smtpauthtype' => 'LOGIN',
'mail_smtpname' => '<ANONYMIZED>',
'mail_smtppassword' => '<ANONYMIZED>',
'mail_from_address' => '<ANONYMIZED>',
'mail_domain' => '<ANONYMIZED>',
'maintenance' => false,
'theme' => '',
'loglevel' => 2,
);
Alles anzeigen
The result is still the same, unfortunately.
I noticed something in the pic you posted yesterday from (what looks like) Windows. Your NC data folder has a red dash on it. I assume this means it's not writable. Are you sure you aren't having a permission issue with the container being able to write to the data folder? I noticed from your pic, you put it inside a Nextcloud folder, along w/ your config folder. I've had permissions issues in the past doing this, thus why I don't generally do that.
I'll try to be around Thursday, this week has been nuts.
KM0201 pic... Windows.... not sure if you confuse me with someone else?
These are the permissions of the data folder:
If these were wrong, it wouldn't have worked locally before.
Interestingly, now opening https://192.168.0.101:451/ leads to ERR_CONNECTION_REFUSED again with overwriting the URL. It might be a belated reaction to the new config.php, but actually I'm not aware of changing anything since then... very very strange.
Current status:
This table shows what I changed (config, before, after) and the result (remaining columns)
config | before | after | domain | domain on phone | from the internet | |
---|---|---|---|---|---|---|
nextcloud.subdomain.conf | set $upstream_app nextcloud; | set $upstream_app nextcloud1; | does not work | works, insecure | - | - |
Tuesday morning initial state | does not work | does not work | works for a while!? | - | ||
/etc/appdata/nextcloud1/config/www/nextcloud/config/config.php | 'overwrite.cli.url' => 'https://nextcloud.<ANONYMIZED>.duckdns.org', | overwrite.cli.url' => '192.168.0.101:451', | does not work | does not work | works for a while!? | - |
hosts | 192.168.0.101 nextcloud.<ANONYMIZED>.duckdns.org | commented out | works for a while!? | - | works for a while!? | works for a while!? |
Some remarks:
Zitat
- "works for a while" is the current state --> I have access for 1-3 minutes, then I get ERR_CONNECTION_REFUSED again (WTF!?)
Ok this behaviour was apparently caused by the desktop & mobile clients trying to connect to NC with the "old" credentials (I chose the same user name and password, but there seems to be a difference anyway). NC or maybe Fail2Ban probably just blocked the connection from my IP after a while.
Now the access works locally & from the internet! Finally after almost 2 weeks nightmare....
It's very interesting though that I set overwrite.cli.url' => '192.168.0.101:451', BUT the access via domain works, also from the internet. NC with Swag remains a mystery for me.
I just restored my calendar app using https://help.nextcloud.com/t/c…ks-as-ics-vcf-files/11978 and the procedure was a bit different for me:
1. I stopped all "new" containers related to NC
2. Commented out everything from the old stack apart from the mariadb section and added the following lines to it:
3. Deployed the stack
4. Followed https://codeberg.org/BernieO/c…ncloud-nextcloud-instance
5. In the /usr/local/bin/nextcloud_dummy/config/config.php I had to set:
The container name, "localhost" or "127.0.0.1" did NOT work! Took me a while to figure this out.
6. Then the script would work and I could download the backup file to my PC via SMB and upload it to the new calendar (old container stopped, new containers started again) via the web GUI
This might be useful for anyone having to restore calendars and contacts from the Nextcloud database.
Hello.
Succeed to set up a Nextcloud behind Swag/Nginx but I want to use the Swag container/Service for another container : Vaultwarden on vaultwarden.domain.com (http://www.domain.com = Nextcloud).
I want to use port 8089 with Vaultwarden as port 80 is already used by nextcloud but I don't want to access https://vaultwarden.domain.com:8089, just subdomain/domain directly. Is it possible ?
I modified a compose.yml file found here : https://linuxiac.com/how-to-in…sword-manager-with-docker to add an "external true" and the name of the network which gives :
version: '3'
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
environment:
- WEBSOCKET_ENABLED=true
- SIGNUPS_ALLOWED=true
- INVITATIONS_ALLOWED=false
- ADMIN_TOKEN=your-admin-authentication-token-here
- DOMAIN=https://vaultwarden.domain.com
- ROCKET_PORT=8089 #I want another port as 80 (defaut one) is already used with Nextcloud on www.domain.com
volumes:
- vaultwarden_data:/data
networks:
- nextcloud-swag_default
networks:
nextcloud-swag_default:
external: true
Alles anzeigen
I also used a proxy conf named vaultwarden.subdomain.conf from https://github.com/linuxserver…den.subdomain.conf.sample and modified it :
## Version 2023/11/12
# make sure that your vaultwarden container is named vaultwarden
# make sure that your dns has a cname set for vaultwarden
# if you are using bitwarden (the official image), use the bitwarden conf
# if you are using vaultwarden (an unofficial implementation), use the vaultwarden conf
#
# vaultwarden defaults to port 80 and can be changed using the environment variable ROCKET_PORT on the vaultwarden container
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name vaultwarden.*;
include /config/nginx/ssl.conf;
client_max_body_size 128M;
# enable for ldap auth (requires ldap-location.conf in the location block)
#include /config/nginx/ldap-server.conf;
# enable for Authelia (requires authelia-location.conf in the location block)
#include /config/nginx/authelia-server.conf;
# enable for Authentik (requires authentik-location.conf in the location block)
#include /config/nginx/authentik-server.conf;
location / {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable for ldap auth (requires ldap-server.conf in the server block)
#include /config/nginx/ldap-location.conf;
# enable for Authelia (requires authelia-server.conf in the server block)
#include /config/nginx/authelia-location.conf;
# enable for Authentik (requires authentik-server.conf in the server block)
#include /config/nginx/authentik-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 8089;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ ^(/vaultwarden)?/admin {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable for ldap auth (requires ldap-server.conf in the server block)
#include /config/nginx/ldap-location.conf;
# enable for Authelia (requires authelia-server.conf in the server block)
#include /config/nginx/authelia-location.conf;
# enable for Authentik (requires authentik-server.conf in the server block)
#include /config/nginx/authentik-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 8089;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ (/vaultwarden)?/api {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 8089;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ (/vaultwarden)?/notifications/hub {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 8089;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}
Alles anzeigen
Restarted Swag/Nginx and get no error, launched vaultwarden with no error in log.
Network inspection of nextcloud-swag_default shows vaultwarden container is connected.
But in the end, https://vaultwarden.domain.com gives nothing.
I set up a CNAME "vaultwarden.domain.com IN CNAME domain.com" before trying the whole thing.
Did I miss something ?
Ok, solved my problem but for information, he re is a method to use already configured and running SWAG container/network to use it as a reverse proxy for another container.
I'll describe for subdomain install for a vaultwarden container running on https://vaultwarden.domain.com.
First, create the CNAME for the subdomain, pointing it to your main domain in your DNS provider (domain hosting provider for me : OVH).
Wait for 1 to 24 hour (you can ping vaultwarden.domain.com on command line to see if it is resolved to domain.com public IP).
Mine is "vaultwarden IN CNAME domain.com." if you modify in text mode (do not forget final point).
You must modify SWAG container (through .yml file, in tutorial, it is the yml file which also set up nextcloud) to load 2 mods and mount the docker.sock volume.
Here is the result (modifications added in red) :
swag:
image: linuxserver/swag #swag is the replacement for letsencrypt
container_name: swag
cap_add:
- NET_ADMIN
environment:
- DOCKER_MODS=linuxserver/mods:universal-docker|linuxserver/mods:swag-auto-proxy
- PUID=1000 #change PUID if needed
- PGID=100 #change PGID if needed
- TZ=Europe/Paris # change Time Zone if needed
- URL=domain.com #insert your domain name - yourdomain.url
- SUBDOMAINS=wildcard
- VALIDATION=dns
- EMAIL=xxx.yyy@provider.com # define email; required to renew certificate
- DNSPLUGIN=ovh
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- /srv/dev-disk-by-label-disk1/appdata/swag:/config #/srv/dev-disk-by-label-disk1 needs to be adjusted
ports:
- 444:443
- 81:80
restart: unless-stopped
Alles anzeigen
Some options are slightly different (I use a wildcard certificat so won't have to regen each time I'll add a container to use this way AND I prefer DNS method, with OVH as a provider, more info on SWAG page directly).
Restart the container.
Now for vaultwarden :
First :read this to understand vaultwarden options put in the YML file : https://linuxiac.com/how-to-in…word-manager-with-docker/
When subdomain is reachable, you need to create your container, using docker-compose.yml, taken from above page :
version: '3.5'
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
labels:
swag=enable
restart: always
environment:
- WEBSOCKET_ENABLED=true
- SIGNUPS_ALLOWED=true #Change to false after first account created and restart container. This setting cannot be changed in admin, even if it showed it changed (bug ?).
- INVITATIONS_ALLOWED=false
- ADMIN_TOKEN=your-admin-authentication-token-here
- DOMAIN=https://vaultwarden.domain.com #subdomain is defined with CNAME on your DNS provider
volumes:
- vaultwarden_data:/data # change to your path if you mapped to a SAMBA share.
networks:
- nextcloud-swag_default #you MUST enter the name of the network created when you set up swag and nextcloud container. Is is created with "name-of-the-compose-file_default" format.
networks:
nextcloud-swag_default:
external: true
Alles anzeigen
That's all.
Launch vaultwarden container after the swag container restart and you can access https://vaultwarden.domain.com and create an account.
I think that for future container you want to connect to the proxy, you just have to add/change the network name to be the swag one + set it true at the end of the file + label swag=enable.
No more proxy conf.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!