Posts by m4tt0

Just ran the regular update procedure to upgrade openmediavault-backup and omvextras today and found the above error code in the console output.

Here the full log entry:

Not sure this is relevant, but wanted to report it, in case it is and others run into it, too...

Yes, my config and data folders are on the raid already. But OK, I'll leave the docker directory itself on the OS NVME drive then. Thanks for your advice, ryecoaaron.

Hmh, interesting. Never thought about this. I'm running OMV from an NVMe SSD M.2 drive. I have sufficient space on there, but just started wondering about "wear and tear". Would you guys recommend moving the docker folder to the HDD Raid instead? And if so, how would you do that with containers being installed?

Solved in the meantime: The problem was caused by Ourosboros running automatic updates on docker.sock, most likely in connection with relatively recent docker upgrades. In any case, once I deactivated Ourosboros all problems were gone...

The problem reoccurs every day at roughly the same time at 12:26/12:27. I've increased the samba log level, hoping to capture more detail on the root cause. You'll find it here (too long to post inline): https://pastebin.com/hbQpys2M

The connection between the containers broke at exactly 12:27:49 today. The log excerpt covers that time stamp, plus previous and subsequent events.

I'd really, really appreciate any insights in what keeps causing this or on how to debug this further...

I use OMV as file and media server. I've been running a Tvheadend container (host mode) and an Oscam container (bridge mode) for several months without problems. Oscam is listening to TVH requests on port 9000. The setup used to work without problems for several months. Some weeks ago, I started to run into issues. At apparently random times (usually once or twice per day), the Oscam container would lose its "connection" to the TVH container and start writing "unknown socket" errors in it's log file. At that stage I also lost my ability to descramble programs via Oscam. Restarting either Tvheadend or Oscam (no matter which) solved the problem and reestablished the proper configuration.

In order to "debug" the problem, I compared the timestamps of when Oscam starts writing the "unknown socket" errors, with the OMV syslog, and found smbd error messages appeared coincidently. Here the output of systemctl status smbd, which describes the errors (the last two lines also appear in the syslog):

● smbd.service - Samba SMB Daemon
Loaded: loaded (/lib/systemd/system/smbd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-09-12 22:07:02 CEST; 22h ago
Docs: man:smbd(8)
man:samba(7)
man:smb.conf(5)
Main PID: 1998 (smbd)
Status: "smbd: ready to serve connections..."
Tasks: 7 (limit: 4915)
Memory: 24.4M
CGroup: /system.slice/smbd.service
├─ 1998 /usr/sbin/smbd --foreground --no-process-group
├─ 2001 /usr/sbin/smbd --foreground --no-process-group
├─ 2002 /usr/sbin/smbd --foreground --no-process-group
├─ 2200 /usr/sbin/smbd --foreground --no-process-group
├─ 2221 /usr/sbin/smbd --foreground --no-process-group
├─10039 /usr/sbin/smbd --foreground --no-process-group
└─32614 /usr/sbin/smbd --foreground --no-process-group
Sep 12 22:07:02 MyRS.local systemd[1]: Starting Samba SMB Daemon...
Sep 12 22:07:02 MyRS.local smbd[1998]: [2020/09/12 22:07:02.268971,  0] ../lib/util/become_daemon.c:138(daemon_ready)
Sep 12 22:07:02 MyRS.local smbd[1998]:   daemon_ready: STATUS=daemon 'smbd' finished starting up and ready to serve connections
Sep 12 22:07:02 MyRS.local systemd[1]: Started Samba SMB Daemon.
Sep 12 22:07:05 MyRS.local systemd[1]: /lib/systemd/system/smbd.service:9: PIDFile= references path below legacy directory /var/run/, updating /var/run/samba/smbd.pid → /run/samba/smbd.pid; please update the unit file accordingly.
Sep 13 12:26:32 MyRS.local smbd[16754]: [2020/09/13 12:26:32.298743,  0] ../source3/smbd/process.c:335(read_packet_remainder)
Sep 13 12:26:32 MyRS.local smbd[16754]:   read_fd_with_timeout failed for client 192.168.1.1 read error = NT_STATUS_END_OF_FILE.  

192.168.1.1 is the IP address of my gateway. Do you have any idea, what "breaks" the connection of the two docker containers? I'm wondering whether the smbd error is causal or just coincident with that breakage, but also don't know how to "debug" this further...

Any help appreciated...

I believed I've figured out the rsyncd / smbd problem. Permissions for the rsync target were not set correctly. Not related. The first part of the question remains though. Any advice appreciated...

gderf Yes, all updates have been installed.

votdev I'm not exactly sure how to check that, but got the following:

root@MyRS:/etc/systemd# systemctl is-active network
inactive
root@MyRS:/etc/systemd# systemctl is-active resolvd
inactive

I do experience regular connection issues across docker containers since some time though. They coincide with the following syslog entries.

Sep 11 00:09:39 MyRS rsyncd[1963]: forward name lookup for unifi.local failed: Name or service not known
Sep 11 00:09:39 MyRS rsyncd[1963]: connect from UNKNOWN (192.168.1.1)
Sep 11 00:09:44 MyRS smbd[1966]: [2020/09/11 00:09:44.986037, 0] ../source3/smbd/process.c:335(read_packet_remainder)
Sep 11 00:09:44 MyRS smbd[1966]: read_fd_with_timeout failed for client 192.168.1.1 read error = NT_STATUS_END_OF_FILE.

Might not be related though and I don't want to hijack the thread...

Interesting. Just checked on my system. I had upgraded from OMV 4 to 5. /etc/resolv.conf was not symlinked. There is no resolve directory within /run/systemd. I ran the omv-salt command, but no change. /etc/resolv.conf just contains my (standard) nameserver entry directly.

Thanks again, votdev. Works brilliantly! My bond is up and running...

Still gave me headaches, but just because of my setup and because I did not really know what I was doing when I started. As this might be useful for others, here a little summary of my learnings:

Situation:

- I have two NICs on my OMV NAS, which are both connected to a managed Unifi 24 Port PoE Switch, which in turn connects to a cable modem via a Unifi Security Gateway.

- I configured everything with my laptop which connects to the Unifi network via Unifi access points and WLAN.

- Objective was to bind the two NAS NICs to increase bandwidth and fail-over security between server and switch

Complication:

- 1: My Unifi Controller docker runs on the OMV server, so "losing" that means I cannot configure anything via my laptop anymore

- 2: I run a Pi-Hole docker on my OMV server, too, so "losing" that means I can neither resolve hostnames nor connect to the internet anymore

Solution:

- It helps to start by removing Pi-Hole from the uplink chain, by reverting to the USG as standard gateway and DNS server in the Unifi controller. Less trouble.

- Before binding the NICs on my OMV server, I aggregated two empty(!) ports on my Unifi switch, to "prepare" the receiving end for the bond. This allowed me to keep the connection with the network.

- Only then, I deleted the network configuration on the OMV server and created the bond, which works now, thanks to votdev's recent changes.

- After applying the new configuration, the bond started configuring.

- I then replugged the two LAN cables coming from the OMV server into the pre-configured aggregated ones, and the bond was active.

- So far so good, but the bond came with a new MAC address, and the Unifi gateway would not resolve the hostname correctly anymore.

- To fix that, I logged into the security gateway and edited /etc/hosts by replacing the MAC address of the old single LAN connection by the new one from the bond.

- The last step was to reconfigure Pi-Hole: I had to delete and recreate the MacVlan network, as the parent had changed to "bond0". Finally, I reinstated it as standard gateway and DNS server in the Unifi controller and all was done.

Quote from votdev

It seems you have a duplicate configuration entry for eno1. Use omv-firstaid to reset the network configuration.

Thanks much! That solved the issue...

I believe I have some hicup in my network configuration after my upgrade from 4 to 5:

If I change the configuration of a network interface, e.g. by simply adding an IP adress for the default gateway, and then apply the configuration, I get the following error:

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; omv-salt deploy run hosts 2>&1' with exit code '1': MyRS.local: Data failed to compile: ---------- 
Rendering SLS 'base:omv.deploy.hosts.default' failed: while constructing a mapping in "<unicode string>", line 32, column 1 found conflicting ID 'append_hosts_eno1_v4' in "<unicode string>", line 76, column 1

 Rendering SLS 'base:omv.deploy.hosts.default' failed: while constructing a mapping
  in "<unicode string>", line 32, column 1
found conflicting ID 'append_hosts_eno1_v4'
  in "<unicode string>", line 76, column 1 in /usr/share/php/openmediavault/system/process.inc:182
Stack trace:
#0 /usr/share/php/openmediavault/engine/module/serviceabstract.inc(60): OMV\System\Process->execute()
#1 /usr/share/openmediavault/engined/rpc/config.inc(167): OMV\Engine\Module\ServiceAbstract->deploy()
#2 [internal function]: Engined\Rpc\Config->applyChanges(Array, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusxu...', '/tmp/bgoutputoi...')
#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#7 /usr/share/openmediavault/engined/rpc/config.inc(189): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
#8 [internal function]: Engined\Rpc\Config->applyChangesBg(Array, Array)
#9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
#11 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
#12 {main}

Do you have any idea how to fix this problem?

Wow. Thanks much, votdev. Truly appreciated! I will report how it goes...

allwan Could you elaborate on how you have achieved that, please? I have two LAN adapters, which are configured individually. I tried and failed several times to link them. My problem was that apparently you have to delete the configurations in order to create the bond from scratch. But removing the configuration, I lost access to the web-ui. It's like a catch 22. I've seen reports working around that by installing WLAN adapters in addition, but could not get those to work either...

As such, any advice appreciated!

Thank You, Sir! That was it. My system is working again...

Gee, what a relief! I increasingly understand why votdev decided not to provide an official upgrade pathway this time.

Just for my understanding: Is it "good practice" now, that

- Shares continue to exist, but do no longer bind to the /sharefolder tree

- The whole /sharedfolder tree should no longer exist/be required

- Instead docker containers should reference the /srv/... tree directly

So, if I adapted all docker containers accordingly, I could disable the sharedfolders again and live happily ever after?

Dear All,

I‘ve tried to install a WLAN Adapter this morning, which failed when trying to apply the configuration. I‘ve tried and failed several times, and always rolled back the configuration again. I gave up and rebooted my NAS. Afterwards all sharedfolders were empty. As I use Unifi in a Docker container, which relies on a shared Appdata folder, my whole network is down as well.

I‘ve recovered from the initial shock, after I‘ve realized, that all my data is still correctly available under /srv/dev-by-disk-.... However, I‘m unable to recreated the sharedfolder structure so my system remains unusable.

I‘ve tried to remove Rsync jobs, SMB shares, deleted and recreated shares via the OMV web-ui, but no folders are created under /sharedfolders anymore.

Any idea how to fix that will be much appreciated.

I‘m on OMV 5.4.7-1 Usul with 5.5.0-0.bpo.2-amd64 backport kernel, if it helps...

I just used ssh to get on my NAS as root, executed cd /etc, and then rm -rf clamd.

Afterwards I closed the ssh session again, went back into the OMV web-interface and reinstalled the antivirus extension. Done.

Fixed:

- I purged the installation of the antivirus extension via the OMV web-interface

- Manually deleted /etc/clamd (flagged as non-empty left-over from the purging process)

- Reinstalled and reconfigured the antivirus extension

Probably just some hick-up from the manual OMV 4 -> 5 upgrade.

Didn't work for me. I'm on 5.4.6-1 Usul, 5.5.0 backport kernel.

Clamav is activated but not running. From the log file it seems the clamav version is outddated and wants to update. During the start-up procedure clamav tries to create the /run/clamav directory, but creates it as root user, not as clamav user. It then fails with Socket file /run/clamav/clamd.ctl could not be bound: Permission denied.

I've tried...

- to deactivate and reactivate it

- to change the /run/clamav ownership to clamav while clamav was deactivated, and reactivating it again

- run omv-salt deploy run clamav

Nothing helps. It cannot bind the socket file. Any other ideas how to fix this?

Gee, that was bumpy! I ran the upgrade procedure today and encountered the same issues hylli ran into, and some more. I'll just be elaborating on the additional ones:

• The upgrade-script exited with errors several times. Similar to hylli I had to "brute-force" my way through the process with dkpg --configure -a, but had to add in some more apt --fix-broken install commands at times, for good measure
• After finalizing the upgrade procedure and clearing the browser cache, I received the following warning: "The property 'numproc' does not exist in the model 'conf.service.nfs'". I found the solution on this forum and could fix it by running omv-confdbadm migrate conf 5.0.0. The error message is gone.
• Then, omv-extras was broken. Whenever I entered into the menu I got the error "The property 'repos.repo.0.uuid' does not exist in the model 'conf.system.omvextras'." I had to purge and reinstall it to get rid of the error.

Finally, the system and my dockers seem to be up and running again. I feel I've aged significantly tonight...