search

ddominet / UDMPRO-samba

UDM-PRO drive bay as a network drive
28 stars 8 forks source link

Error adding network: failed to create bridge "cni0": could not add "cni0": operation not supported #2

Open LexxM3 opened 2 years ago

LexxM3 commented 2 years ago

After fixing the script to use 'podman ps -a" (rather than the syntax error of '-all'), I am now getting the following podman error:

Not a podman or cni expert here. Any thoughts?

LexxM3 commented 2 years ago

Experiment: I've simplified the samba.sh script for myself by moving the container networking setup to its own on_boot script. I've then tried to set up an alternate container mostly as a test; specifically an iperf3-server per the basic outline at link below (mlabbe/iperf3:latest container used). @jekhokie

https://jekhokie.github.io/unifi/networking/iperf/performance/2020/12/08/iperf-on-unifi-dream-machine-pro.html

Result: exactly the same error set.

Conclusion: it seems something changed or broke in UDM-PRO software since all these tutorials were originally published. Again, I am not even slightly a podman or CNI (or UDM shell environment) expert (but am ramping up a little now), so don't really know where to look to try to fix things, but it seems it's something in the UDM-PRO CNI base setup. Any guidance would be helpful.

LexxM3 commented 2 years ago

Made progress and I am now able to connect.

It seems samba.sh (and @jekhokie's iperf3-server instructions per above) as it currently stands has an assumed undocumented dependency on something in the boot environment executing a ip link add cni0 type bridge command to add the cni0 interface, something my setup didn't have as it wasn't part of one of the two documented methods of setting up on_boot.d facility. Once that's in place, samba container starts to run and I am able to access it. Need to REALLY cleanup the script AND the documentation of dependencies for this to be useful for others. TODO.

Also learned that UniFi OS UDM Pro 1.11.0.3921 doesn't play well with podman 3.3.0, so it's best to leave it at stock (ancient 1.6.x) until things get figured out.

Addendum 1: Win 10 requires a reversal of policy rule to allow guest SMB access. See here: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/guest-access-in-smb2-is-disabled-by-default. Regardless of what it seems to indicate, Win10 Pro DID NOT allow guest access by default (i.e. AllowInsecureGuestAuth was set to 0 and had to be changed to 1 to allow guest access).

thealpa commented 2 years ago

Since @ddominet doesn't own his UDM-Pro anymore, I've created a fork with a cleaned up script, user authentication and updated documentation: thealpa/UDMPRO-samba

LexxM3 commented 2 years ago

Since @ddominet doesn't own his UDM-Pro anymore, I've created a fork with a cleaned up script, user authentication and updated documentation: thealpa/UDMPRO-samba

Awesome setup, much cleaner, thank you!

Going just a little more advanced in terms of user management ...

While -u "user;password" is a very simple approach, it requires the password(s) to be in the clear on the host. Is there a suggested way to setup and manage Samba users in the container where the password can be properly encrypted or hashed at all times?

Of course one can setup users inside the container using useradd and smbpasswd -a facilities, but the real issue then is how to persist those users between container kill/run/reboot cycles?

An example or two for above issues would be helpful to many.

thealpa commented 2 years ago

Storing passwords as a hash won't work since dperson/samba doesn't accept anything other than plain text. Considering the container hasn't been updated in a while, it might be worth considering switching to a different one anyways.

For now it's certainly an option to store username(s) and password(s) in a config file separate from the script, maybe along with additional configuration options. Feel free to open an issue here with any options that you'd like to see.