Bungy

Hmm sounds like the owner of your config.php file is off. Try running this from within the docker as the root user: chown www-data:www-data /var/www/html/config/config.php Then retry the previous commands.

Then yeah the www-data user is automatically created. It looks like you didn't successfully switch your console to the www-data user which is what happens in that third command I sent you. Double check for typos.

Which docker container are you using? The official one or l3iggs?

I'm uncertain which docker you're asking for help with. Is this a general unraid question or related to one of the dockers that I support? Apologies, I forgot this was a general repository thread. My question is specifically related to the OwnCloud docker. I've never performed these actions, but you may be able follow the instructions in this link to rescan the file system: https://doc.owncloud.org/server/8.0/admin_manual/configuration_server/occ_command.html#file-operations As far as moving the files around, you can probably move them like you have an run the command in the above link. Remember you'll have to do this from within the docker. Let me know if you have issues with any of that and I may be able to help. I saw this documentation, I think my issue is coming from running the command from inside the docker, I'm not 100% sure how to do that. If you could point me in the right direction of even how to figure that out that would be amazing, as my searching hasn't turned out to be fruitful. When i try "cd" /var/www/owncloud" I get no such file or directory. I have "/var/www/html/apps" mapped to "/mnt/cache/appdata/owncloud/apps", and config mapped to the same but config instead of apps. When I try and run "sudo -u www-data php occ list" I get "unknown user www-data" and "unable to initialize policy plugin" in each of those directories. I must just be looking in the wrong place but I can't find "occ" or "console.php" anywhere on my server. So I think I understand how to execute in the docker. I tried: docker exec -it owncloud bash which returns root@(numberstring):/var/www/html# but when I then try and run sudo -u www-data php occ it returns bash: sudo: command not found This worked for me: docker exec -it owncloud bash chsh -s /bin/bash www-data su - www-data cd /var/www/html php occ files:scan That will show you the options for scanning files. When done, make sure you run this to return the www-data user to normal chsh -s /usr/sbin/nologin www-data

I'm uncertain which docker you're asking for help with. Is this a general unraid question or related to one of the dockers that I support? Apologies, I forgot this was a general repository thread. My question is specifically related to the OwnCloud docker. I've never performed these actions, but you may be able follow the instructions in this link to rescan the file system: https://doc.owncloud.org/server/8.0/admin_manual/configuration_server/occ_command.html#file-operations As far as moving the files around, you can probably move them like you have an run the command in the above link. Remember you'll have to do this from within the docker. Let me know if you have issues with any of that and I may be able to help.

I'm uncertain which docker you're asking for help with. Is this a general unraid question or related to one of the dockers that I support?

My guess is you have an issue with the postgres container that happened around March. Check this out: https://github.com/sameersbn/docker-gitlab/issues/39#issuecomment-203117506

How long ago was your last gitlab container update?

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?