Hello. I have read lots of posts in this forum and a lot more on the web in regards to my situation but they were not that similar, or when I did the solution to the issue it didn´t work. So I decided to post to get help from more seasoned people.
Since last week I have been using lxc containers inside my proxmox instance. I made a folder in the host that has the ownership by a common group between all lxc containers. So, with that I created a lxc container who actually shares the files with my lan. I added both nfs and samba for sharing it. Creating both through the cli instead of any ui. Later on, for testing stuff I added cockpit and this is where I started to see the issues. Accessing the web-ui is completely random, sometimes it works, other days it won´t.
When it doesn´t want to connect to the webui the error is always: "connection reset by peer". The strange thing is that this behavior repeats itself all the time on different containers on the same node. I could never access any webui that are being served from any lxc container from my lan, I tested it also with jellyfin and webmin. The behavior is always the same: "connection reset by peer" this happens also SOMETIMES when I ssh into the containers.
The actual samba share as well, sometimes is available, most other times not. The error is also always "connection reset" when I try to access it through say, nautilus or through the command line by cifs.
I have tried disabling ssl on cockpit and webmin to test, the behavior is still the same. "connection reset by peer"
That led me to believe I am being firewalled by something along the process, but I already tested the container with its firewall option on proxmox disabled, and also disabled the main proxmox firewall.
This is a bit of info on those containers:
To add to my confusion is that I have a bare-metal debian install running jellyfin and ripping my physical media which I planned to move into an lxc container. It is accessing the files with nfs from the "share" container at 192.168.70.110 fine.
Here is some info on it:
And its fstab:
The "test" container holds an instance of webmin for no particular reason, hence, "test". The "share" one is the one responsible to share the data
Any pointers from you guys would be much appreciated. I am pulling my hair trying to understand what I am doing wrong.
Since last week I have been using lxc containers inside my proxmox instance. I made a folder in the host that has the ownership by a common group between all lxc containers. So, with that I created a lxc container who actually shares the files with my lan. I added both nfs and samba for sharing it. Creating both through the cli instead of any ui. Later on, for testing stuff I added cockpit and this is where I started to see the issues. Accessing the web-ui is completely random, sometimes it works, other days it won´t.
When it doesn´t want to connect to the webui the error is always: "connection reset by peer". The strange thing is that this behavior repeats itself all the time on different containers on the same node. I could never access any webui that are being served from any lxc container from my lan, I tested it also with jellyfin and webmin. The behavior is always the same: "connection reset by peer" this happens also SOMETIMES when I ssh into the containers.
The actual samba share as well, sometimes is available, most other times not. The error is also always "connection reset" when I try to access it through say, nautilus or through the command line by cifs.
I have tried disabling ssl on cockpit and webmin to test, the behavior is still the same. "connection reset by peer"
That led me to believe I am being firewalled by something along the process, but I already tested the container with its firewall option on proxmox disabled, and also disabled the main proxmox firewall.
This is a bit of info on those containers:
Code:
~ pct list
VMID Status Lock Name
110 running share
111 running test
➜ ~ cat /etc/pve/lxc/110.conf
arch: amd64
cores: 2
features: mount=nfs;cifs,nesting=1
hostname: share
memory: 512
mp0: /main_pool/data/bin,mp=/mnt/network/bin
mp1: /main_pool/data/containers,mp=/mnt/network/containers
mp2: /main_pool/data/downloads,mp=/mnt/network/downloads
mp3: /main_pool/data/git,mp=/mnt/network/git
mp4: /main_pool/data/media,mp=/mnt/network/media
mp5: /main_pool/data/public,mp=/mnt/network/public
mp6: /main_pool/data/work,mp=/mnt/network/work
mp7: /main_pool/shared_storage,mp=/mnt/network/shared_storage
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.68.1,hwaddr=BC:24:11:7B:ED:67,ip=192.168.70.110/24,type=veth
onboot: 1
ostype: debian
rootfs: main_pool:subvol-110-disk-0,size=8G
startup: order=1
swap: 512
lxc.apparmor.profile: unconfined
➜ ~ cat /etc/pve/lxc/111.conf
arch: amd64
cores: 2
hostname: test
memory: 512
net0: name=eth0,bridge=vmbr0,gw=192.168.68.1,hwaddr=BC:24:11:BD:A5:0B,ip=192.168.70.111/24,type=veth
ostype: ubuntu
rootfs: local-lvm:vm-111-disk-0,size=8G
swap: 512
To add to my confusion is that I have a bare-metal debian install running jellyfin and ripping my physical media which I planned to move into an lxc container. It is accessing the files with nfs from the "share" container at 192.168.70.110 fine.
Here is some info on it:
Code:
➜ ~ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 7c:83:34:bb:42:28 brd ff:ff:ff:ff:ff:ff
inet 192.168.70.3/22 brd 192.168.71.255 scope global dynamic enp1s0
valid_lft 4814sec preferred_lft 4814sec
inet6 fe80::7e83:34ff:febb:4228/64 scope link
valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 7c:83:34:bb:42:29 brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:3e:ca:af:7c brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:3eff:feca:af7c/64 scope link
valid_lft forever preferred_lft forever
8: veth4a319cb@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 8a:18:f2:21:46:7c brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::8818:f2ff:fe21:467c/64 scope link
valid_lft forever preferred_lft forever
12: veth9eca693@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 6e:cc:2f:46:6b:17 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::6ccc:2fff:fe46:6b17/64 scope link
valid_lft forever preferred_lft forever
And its fstab:
Code:
➜ ~ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/mediaServer--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/nvme0n1p2 during installation
UUID=7bb4073c-e50e-47ea-a3d2-3e4fcc2ffbab /boot ext2 defaults 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=2132-BFBC /boot/efi vfat umask=0077 0 1
/dev/mapper/mediaServer--vg-home /home ext4 defaults 0 2
/dev/mapper/mediaServer--vg-tmp /tmp ext4 defaults 0 2
/dev/mapper/mediaServer--vg-var /var ext4 defaults 0 2
/dev/mapper/mediaServer--vg-swap_1 none swap sw 0 0
192.168.70.110:/mnt/network/media/books /mnt/network/books nfs noauto,x-systemd.automount 0 2
192.168.70.110:/mnt/network/media/videos /mnt/network/videos nfs noauto,x-systemd.automount 0 2
192.168.70.110:/mnt/network/containers /mnt/network/containers nfs noauto,x-systemd.automount 0 2
192.168.70.110:/mnt/network/downloads /mnt/network/downloads nfs noauto,x-systemd.automount 0 2
192.168.70.110:/mnt/network/media/music /mnt/network/music nfs noauto,x-systemd.automount 0 2
The "test" container holds an instance of webmin for no particular reason, hence, "test". The "share" one is the one responsible to share the data
Any pointers from you guys would be much appreciated. I am pulling my hair trying to understand what I am doing wrong.
Last edited: