[SOLVED] Access to samba/nfs or any webui of any lxc container always errors with "connection reset"

brunosxs

New Member
Sep 23, 2023
2
1
3
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:
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:
omg, rubber-ducking by just writing this made me realize I have the subnet mask wrong for those lxc containers to be properly exposed into my lan. That is basically the real cause of the issues. My router has an dhcp server that uses /22 but on those containers I used /24
 
Last edited:
  • Like
Reactions: leesteken

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!