OK, just as I expected: For some reason the fail2ban process no longer identify itself as "f2b" anymore. Instead it now uses "fail2ban". I therefore need to change app-domoticz so it check if "fail2ban" is running instead of "f2b". I will try to fix this early next week.
Note: There are no "real" problem here. As long as fail2ban is running, everything is fine. It is just that app-domoticz is indicating a "false" alarm when it can not find "f2b" running...
Serviio version 2.2 is now available for ClearOS 7. If you want to update your existing serviio version you will have to do it manually from command line: NOTE: Any "Pro licence" that you may have for Serviio 1.x will NOT work with Serviio 2.x , so if you update and still want the Pro-features, then you need to go to https://www.serviio.org/ and purchase a new licence.
Since the 2.2 version will make any 1.0 licence unusable, I am planning to keep Serviio 2.2 in contribs-testing and not release it into the normal contribs repo (because then the update will be forced upon everyone that has auto-update on).
Maybe I get some time during the weekend to look at this. If the changes are minor, which it says in the release notes, then I think I can put it in contribs-testing within a week after some testing first..
If I understand it correctly there are two different "plugin Managers", and I assume you have tried to installed the second one named "Domoticz Plugin Manager", correct?
Can you describe how you tried to install it in a bit more detail and please also the "trace" leading up to the "startup variable"?
In ClearOS the Domoticz the executing (working) directory is (and should be) /usr/share/domoticz . However, the userdata, webserver files and database pahts are different ( /var/domoticz ) and this is set at the startup of Domoticz. In Debian based systems (such as Raspberry Pi) it looks different. My assumption is that there is some "hardcoded" path in the plugin modules part that is assuming a Debian file structure which is then causing the trouble.
I am pretty sure the plugins should be installed in /var/domoticz/plugins/ .. Also, make sure that domoticz is owner of the files (recursive in all sub-directories)
I might be mistaken, but I think the bug-fix that was made to Domoticz Plugin Manager inCommit #16 was not the best... "StartupFolder" should have been "UserDataFolder" instead (two places). Also, they seem to have forgotten about fixing a row in plugins-manager/manager.py in row 80 also. it says:
which I guess mean it takes current working directory (set to /usr/share/domoticz ) and add /plugins so the final path to where it "thinks" it sits is "/usr/share/domoticz/plugins/ ". Which obviously is not correct.
With Domoticz Plugin Manager installed in /var/domoticz/plugins , owner set to domoticz, and with line 63 and 79 changed so it says "UserDataFolder" instead of "StartupFolder" (and hardcoded the row 80 in manager.py to "/usr/share/domoticz/plugins" it seems to work a bit better. I do not have time right now to "install" a plugin from the menu. But you can try this first if it is possible to experiment on your side.
I do not use python plugins myself so I have not seen this. But I will investigate a bit, and the info you provided is a good start.
Unfortunately I do not have access to my normal development environment right now so it may take a few days. Setting up a virtual machine right now for trouble shooting.
Thanks Nick for testing, the problem is on a more fundamental level so if it works with flexshare it should not be a problem with printer sharing.
I did some more testing, and now I am more confused than ever... It could be that the problem is specific to my machine/setup only:
1. I did update my development machine as well. ( It did have "server max protocol = NT1" in the smb.conf file both before and after the update. ) No problem to connect to it from my Windows 10 clients before or after the update.
So maybe something bad have happened to my normal server that has been running ClearOS 7 24/7 since it came out some years ago without me changing any samba configuration for more than 2 years or just about anything else with it either...
2. So I decided to play a little bit more with my normal server that experienced this update problem.
a. First I verified that file and print sharing still worked from my Win10 client (with protocol = SMB3 in the smb.conf file)
b. I removed the protocol = smb3 and saved the file. -> I could see in the Win10 client that my server disappeared a few seconds (I think I have read that Samba automatically reconfigure itself whenever smb.conf is changed) -> I could still connect to the flexshares from the Win10 client
c. Then I typed "systemctl restart smb" -> Now I could not connect to the flexshares anymore
d. I entered the "protocol = smb3" line again into smb.conf and saved the file -> In Win 10 client I saw the server disappear and come back -> Still got "RPC error" when trying to connect
e. I restarted the smb.service again, and now I could connect again.
Now I was pretty confident that the line "protocol = smb3" was the magic thing "solving" my issue for some strange reason. As you say, this line in practice means that it is using the same value as default (without the line)...
However, I did one more test (2b - 2e above), however it was no longer possible to connect to my server from my Win10 client. I repeated these steps probably 20-30 times without any success. I even tried to change "smb3" to "smb3_11", "smb3_02", "smb2", "NT1". For all protocol versions except smb3 and smb3_11 my Win10 client complained that it could not reach the server, but for smb3 and smb3_11 I got the RPC error.
So clearly(?) the protocol=smb3 line was not the magic solution. But for some reason it worked for a while...
Thinking about the error about "bad character" I started to think it could be a character set problem (remember my Win 10 clients are running Swedish setup). So instead of the protocol = smb3 line I entered (also under the global section): "unix charset = UTF-8" in smb.conf file, saved it and restarted the smb.service -> Now I could access the flexshare from my Win10 client again!
Given my previous experience I had to undo/re-enter this line again -> Result: Removing the line prevented Win10 client to connect, Adding the "charset" line back did however not work.... So the root cause is probably not a "charset" problem.
So, my conclusion now is that I must have some problem in my setup/config somewhere and this smb.conf editing & restarting smb.service is just triggering it somehow. It seems, apart from the first couple of rounds with the protocol line, that when I save something "new" in smb.conf that has not been there before then it works until I restart the smb.service next time. Now, I do not have time to trouble shoot for quite some time and I needed flexshare and my printer sharing to work again, so for now I have entered the line "dos charset = cp865" in smb.conf and restarted smb.conf. Now I am fine until next restart and then I will likely need to come up with a new parameter to set in smb.conf
Ok, this is what I did that seems to work:
Add the following line under the [Global] section in /etc/samba/smb.conf
I had no other "protocol" line in the smb.conf file before, and before the update of Samba I was on 4.10.16-13 and it worked fine. For some reason it seems to be neccessary to set the protocol level now...
Last night Samba was updated to 4.10.16-15 in my Community machine. Today I realize that my windows 10 clients cannot reach flexshares or print to the printers connected to the cups server. I think something is broken with Samba.
I am using "simple networking"
In my Windows 10 client I get "RPC protocol error" message whenever I try to reach a flexshare or try to print. In the samba log I get messages like this for each attempt from my Windows client:
The "Bad character push conversion with flags" looks "interesting". Note that my Win 10 clients uses Swedish setup (but my flexshares and printers use the normal english alphabet only)
Anyone that experience this too or know what to do?