Bungy

I'm having an issue with mounting an ISO. Each time I get a readme.txt inside the mount point saying: This disc contains a "UDF" file system and requires an operating system that supports the ISO-13346 "UDF" file system specification. It works fine if I manually mount (mount -o loop file.iso mountpoint). Any thoughts?

Possibly. I haven't tried any of the zwave stuff yet, so my only suggestion would be to hop on the home assistant forum/gitter. They're really helpful and the gitter is a great place to get answers quickly.

Interesting. I'm not familiar with setting up zwave devices, but I would assume the software has nothing to do with the controller's connectivity with your lights, unless the software is responsible for setting the transmit signal strength. You say homegenie is working well - is that also in a docker? Have you tried running home-assistant natively on another machine?

I do this often with an X10 usb controller. Add to your extra parameters section. Run these to check that it worked:

Are you sure your postgresql container is up and running? It looks like docker can't find it. based on logs, yes... Postgres is running fine. Autovacuum has been started by itself so it has to be running. Its true that Postgres container is not starting up after server reboot (and its set to autostart) but im pretty sure its running. Log: LOG: MultiXact member wraparound protections are now enabled LOG: database system is ready to accept connections LOG: autovacuum launcher started do u think it could help if I removed postgres and install it again? If your postges docker needs to be manually started, it may be that the gitlab docker started trying to run before the postgres was online. Try to stop all of the dockers (redis, postgres, and gitlab) and then start them in that order (redis, postgres, gitlab).

I haven't tried the nginx proxy yet, but it's on my todo list. I'll probably end up using jwilder's nginx proxy (https://github.com/jwilder/nginx-proxy) since it has automatic setup based on environmental variables.

Are you sure your postgresql container is up and running? It looks like docker can't find it.

When did this crop up? It looks like an issue with your mariadb setup. This is the error: General error: 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. This is outside of what I know about mysql/mariadb off hand, but you may be able to google around and see if you can find a fix. Thanks so much for helping. I finally tracked the issue to the bin log format reverted. I had to set it back to mixed. I really appreciate the help. Bill Awesome man. I'm glad it all worked out for you.

My first question to you - are you set on using openhab? I've found that it's pretty annoying to configure and easy to screw up. If you're set on using openhab, I'll help you debug, but I'd steer you towards home-assistant. It's far less buggy, easier to develop for, and making quicker strides than openhab.

When did this crop up? It looks like an issue with your mariadb setup. This is the error: General error: 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. This is outside of what I know about mysql/mariadb off hand, but you may be able to google around and see if you can find a fix.

I really appreciate any help with this issue. If I did not provide enough info to troubleshoot please let me know. I really need to get this issue resolved. If it is easier, how can I try a complete reinstall and not lose my info already uploaded? Thanks Bill That's really strange. Can you post your config.php with sensitive info removed? Yes once sec. I also had a though. was having problems with a share. Part of the troubleshooting was to run check reiserfs. So I stopped owncloud, mariadb, apache, then the array. I placed it into "maintanence mode". Ran the check (only on the the dick that contained the problem share, nothing to do with "owncloud". The check completed with no issues. I started the array. I do not think I messed with Owncloud at all but since then I have had this issue. I am wondering if I could've messed with say file security rights or something. I changed a few things in the config.php and nothing made a difference. Here you Go: <?php $CONFIG = array ( 'instanceid' => 'oc2twvg4kdgg', 'passwordsalt' => 'secret', 'secret' => 'secret', 'trusted_domains' => array ( 0 => '192.168.2.97', 1 => 'hunterstec.com', ), 'datadirectory' => '/var/www/html/data', 'overwritewebroot' => 'owncloud', 'overwriteprotocol' => 'https', 'overwrite.cli.url' => 'https://hunterstec.com/owncloud', 'dbtype' => 'mysql', 'version' => '9.0.1.3', 'dbname' => 'owncloud', 'dbhost' => '192.168.2.97', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud', 'dbpassword' => 'secret', 'logtimezone' => 'UTC', 'installed' => true, ); Your config looks good. The only difference between our setups is I also have this option: 'overwritehost' => 'hunterstec.com', Try adding that in right below overwrite protocol and see of that helps. You may need to restart the container after you make the change.

I really appreciate any help with this issue. If I did not provide enough info to troubleshoot please let me know. I really need to get this issue resolved. If it is easier, how can I try a complete reinstall and not lose my info already uploaded? Thanks Bill That's really strange. Can you post your config.php with sensitive info removed?

@hunter69, you might want to look at my config files above....including Bungy's advise it is running all well now. @Bungy, thank you so much, I was really desperate without ownCloud. I will not move away from apache reverse proxy for now as I have a running system again. The letsencrypt docker would have been a great replacement but it was running a couple of days and stopped working at all. fail2ban and the ssl certificate renewal are great features but if the whole thing isn't running .... Maybe I will follow you as soon as you got it up and running Hmm, I'm not aware of a container with letsencrypt and fail2ban. Can you point me to which container you're talking about? I'd love to try that out.

Awesome! Yeah that's definitely the cleanest way to go.

Yeah, your reverse proxy looks like it's working correctly. Otherwise you wouldn't get the white screen with the login prompt at all.

Yeah, there was a misunderstanding there. All you have to do is add or edit these lines inside of your config.php file: 'overwritewebroot' => 'owncloud', 'overwrite.cli.url' => 'https://server.com/owncloud', Make sure you replace server.com with your hostname.

Why do you want to change the install directory to that path? Changing that will get reset whenever the container is recreated and could be harmful to the container. What issue are you trying to solve?

Yeah, i've seen that before. You need to set up your owncloud container to serve the static files on /owncloud. Add or edit these lines in your config.php file 'overwritewebroot' => 'owncloud', 'overwrite.cli.url' => 'https://server.com/owncloud', Then reboot the owncloud container and you should be good to go.

My config is quite a bit different from yours. Looking at the error.log file for your apache container should help. This should be exposed in the volume mount for your apache container (/config). Try changing: ProxyRequests Off ProxyPreserveHost Off ProxyPass / https://192.168.178.28:8000/ ProxyPassReverse / https://192.168.178.28:8000/ To: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so <Location /> ProxyPass http://192.168.178.28:8000/ ProxyPassReverse http://192.168.178.28:8000/ </Location> Note: If you're using the official owncloud container, you should point to http instead of https as changed above. I'm in the process of changing my reverse proxy over to nginx reverse proxy by jwilder since it has auto-generation of configuration. You may want to take a look at that as well (https://github.com/jwilder/nginx-proxy).

Nice! Yeah I switched to Hass about two months ago and never looked back. I found its much more stable and I like developing in python way more than java.

Currently, openhab has been lacking updates because I'm no longer using it. Also, it's a nightmare of a docker/enviornment to set up, so I dread having to update it. I'll work on pushing an update soon.

Yeah sorry about that. I'll update the template to point to the right container repo. That docker is extremely beta - I couldn't get it to work well and abandoned it. I haven't touched it in months so proceed with caution.

The official owncloud container does not have HTTPS built in. I would recommend setting up a reverse proxy using linuxserver.io's apache container. You'll have to add https to the reverse proxy container and have that container forward requests to your owncloud container.

Instead of entering the docker, edit your config file from your host. The file is likely located somewhere like /mnt/cache/appdata/owncloud/config/config.php. Then simply restart the docker and you should be good to go.

# To enter the docker shell docker exec -it owncloud bash # To show the contents of the config.php file cat config/config.php # To check the permissions of config.php file ls -l config/config.php