Beiträge von keinhen

  • Greyed out video files when accessing from OSX / Mac in Finder

    Hello everybody,

    I've set up an Openmediavault 5.5.17-3 (Usul) as a project NAS in our audio production company, where my current computer is a Mac Pro 5,1 running High Sierra 10.13.2.

    Generally it has worked fine, but I've come across an odd compatibility issue with OSX when it comes to storing video files. On some video files, apparently at random, it will grey out the icon, and behave erratically when transfering / copying / opening. Ive noticed the following issues:

    1. When I drag and drop files from the NAS in finder to say my desktop, it will show the progress bar and transfer time correctly, but once it reaches completion the file will simply vanish from the receiving computer as if it wasn't even transfered.

    2. When I try to move a file on the NAS to another directory on the NAS in Finder, it warns me: "Some of the items you are moving are in use by another application. Moving the items can cause prolbems with the application using them. Are you sure you want ot move these items?", but if I proceed it moves them without issue.

    3. When I try to copy a file on the NAS to another directory on the NAS in Finder, it prompts me with: "One or more items in "video.mov" can't be changed because they are in use"

    4. Folders also ocassionaly grey out, but it resolves simply by double clicking the folder and entering it.


    5. Previewing the videos with Apples own preview tool by space clicking the file in Finder allows me to watch the file even if gray, but opening it in VLC or Quicktime fails.

    For a while I believed it to be user permission / CODEC related, but some (not all) greyed out video files persist between different users, and the greyed files are of a wide range of formats / CODECs including mp4, mov, Apple ProRes and Avid DnxHD.

    None of these issues are present when I ssh in or access the sambashare via Thunar on my personal Linux machine, and I can even remedy persisitng grayed out files by simply copying the file in Thunar to replace the previous file.

    Most greyed out files persist between reboots as well.

    Anybody experienced anything similar, or know where to start looking to troubleshoot? I suspect it's more of an Apple/Mac issue than an OMV one, but I thought I'd start asking here anyways. Some previous threads on similar issues yielded little results for me after attempting their terminal command fixes for the files.

    Thanks a bunch!
    - Henry

  • rrdcached error messages after reboot

    I'm having a similar set of issues with rrdcached on an OMV 5.5.16-1 (Usul) system.

    Get two emails on reboot, one that rrdached "does not exist" and isn't running, and then subsquently one that it is running moments later.

    systemctl status rrdcached informs me that the process is running fine, and in the /etc/default/rrdcahed I find everything similar to Chudak above, main thing being that everything is at /run/ and not /var/run/, I gather as previous commenters have had issues with that.

    In /var/log/syslog I find this sequence:

    monit[871]: 'rrdcached' process is not running
    monit[871]: Cannot create socket to [127.0.0.1]:25 -- Connection refused
    monit[871]: Cannot open a connection to the mailserver 127.0.0.1:25 -- Operation now in progress
    monit[871]: Mail: Delivery failed -- no mail server is available
    monit[871]: Adding event to the queue file /var/lib/monit/events/1605598308_55f4e3545770 for later delivery
    monit[871]: 'rrdcached' trying to restart
    monit[871]: 'rrdcached' start: '/bin/systemctl start rrdcached'

    I think the mail server at :25 might be unrelated, and I don't fully understand it, but I still included it in case it is pertinent.

    If anyone has any ideas how to adress this it would be great, though at this moment it seems like a minor inconvenience I guess?

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Good to know about the overwrite!


    And also good to hear this isn't a new frontier for the people here either, will definitely give this a try.


    I went to /srv/dev-disk-by-name-disk1/appdata, but there is no "mariaDB" folder, there is letsencrypt / nextcloud / nextclouddb available. Are we talking about the nextclouddb, or should I have mariaDB named folder in here?


    Thanks again Morlan! You've been incredibly helpful with this.

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    @draddy Thank you! I went and reread my config file as well, and noticed the line 5 closed the config brackets before reaching the rest of the info, should've caught that earlier! Now I am able to get to the nextcloud admin creation page.


    I still feel a bit disheartened as now I'm having some kind of issue with mysql and mariadb..


    When I try and create an admin user in the nextcloud install wizard prompt I receive the error message:


    "Error while trying to create admin user: Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [1045] Access denied for user 'root'@'nextcloud.nextcloud_default' (using password: YES)"


    I followed the "How to" exactly, using my MYSQL_ROOT_PASSWORD as the password for the user "root", and then tried to make a MariaDB/MYSQL database with the database: nextcloud and database host: nextclouddb, which seems to line up with what's written in the docker-compose.yml file.


    I tried searching around for answers to the issue, and they pertained to creating a new database / user in CLI instead of the nextcloud wizard, but I didn't seem to have any luck following their instructions.


    Does anybody here have any experience with this very final issue? :D


    (Also, oddly enough I can only access the https://nextcloud.xxx.duckdns.org, all other URLS, including the localip:444 still send me to the "Welcome to our server" page. Is this normal?)

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Zitat von Morlan

    @keinhen were you successful in accessing Nextcloud locally?


    @draddy I’ll be back in 3 weeks. This German guide (https://decatec.de/home-server…ce-mit-eigener-subdomain/ ) helped me.

    Before successfully obtaining the cert from letsencrypt, when I was still receiving error messages from "docker -f logs letsencrypt", I was able to access nextcloud locally.


    Now when I type localip:444, I receive security warnings that caution about proceeding to the website, like I used to have when I had a nextcloudpi instance running successfully. Also, if I forget the https:// prefix, I get this warning



    This also used to happen, so I take it as a sign I've gotten closer.


    But in short: no, I can't access nextcloud locally anymore.

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Zitat von Agricola

    @keinhen I’m no Linux power user but I have tried and failed (and succeeded) installing Nextcloud enough to know that when you get to “Welcome to Our Server” you are getting really close.

    • That means you have correctly/successfully set up your container and have generated a valid cert. Don’t start over!
    • Your config.php and Nextcloud....conf files probably just need fine tuning.
    • If you are knocking on the Nextcloud setup page but receiving error messages, then your files in #2 above are correct, and you just don’t have the right info inserted in the setup page. Go back to @macom’s [How-To] and follow that last section precisely. When I first used that guide I remember inserting information hanging around in my mind from previous guides, and kept wondering why I was getting those errors. Finally I decided to slow down and read each line of the final setup (slowly) and was amazed that it worked. I’m not saying this is your problem but it could be.

    Good luck.

    Thanks for the pointers!


    Reading through slowly and not rushing definitely usually is the key, but I am still left confounded. I guess the issue is with the config.php and .conf files, but I can't seem to find anything awry, and I have tried back and forth tweaking a few parameters relating to port numbers to double check for the all-to-probable human error i've added into the mix. I'll have to keep looking at them and referencing @macom 's howto! It's just a bit tough going line by line as I am using both the subdomain and duckdns variants listed in the comments to get things up and running, so there is no clear one page read-through :D maybe a cup of coffee on a less busy morning could be what gets this finally past the finish line.


    Thanks again!

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Zitat von Morlan

    Just to be clear. The message is the "Welcome to our server"?


    I dont see any faults in the configs. Can you post the output of the access.log from /srv/dev-disk-by-label-disk1/appdata/letsencrypt/log/nginx directly after trying to connect to your url?

    This is what I see, so yes.


    Also when attempting nextcloud I get:


    My access.log (sorry if there's some extra, it was a long file so I copied the ones with the relevant timestamp.)




    Would there be any point in starting over, could there be something erroneously configured / set now that I have been trying out many different things?


    Cheers, and thanks again for the help!

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Zitat von Morlan

    Looks like you also posted the subdomain config in the subfolder part.
    Did you use the guide so far (docker-compose to set it up) so that letsencrypt and Nextcloud are connected in a docker network?
    For subdomain method did you specify a Nextcloud subdomain when setting up letsencrypt (SUBDOMAINS=www,nextcloud)?

    Ah yes I forgot to post my docker-compose.yml file!



    Yeah I used the docker-compose setup 1-to-1 as in the how-to, the subdomains have both www and nextcloud.
    My disk is called disk1 as to avoid confusion in the long naming strings this time around, and I have added a duckdns image / container into the mix as someone was advised in a related thread, but I don't know if its necessary as its not part of the primary how-to?


    I'm also puzzled by what you mean by "posting the subdomain config to the subfolder part", did I mess up posting it here or somewhere in my config files?


    Currently I tried and deleted the other (subfolder) config file, and now currently have this as my subdomain.conf file, but nothing has changed yet.



    Thanks for the help!

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Ah!


    Good catch, just a plum old mistake on my part. Switched out the array to 1 =>, and deleted my subfolder.conf file as to avoid any overlap.


    Once I did this I rand "docker-compose up -d" at my directory with the .yml file, restarted letsencrypt, ran "docker logs -f letsencrypt" and restarted nextcloud, but all is the same..


    Accessing nextcloud via nextcloud.xxx.duckdns.org, or localip:444 results in error messages, as does accessing omv via duckdns or localip.


    But thanks for the doublecheck, that would've definitely kept me bugged down if that was in the mix :D

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Hello!


    I am able to get to the final stretch of this tutorial with letsencrypt returning a working cert and all my containers running without any error messages, but once I have all my containters up and running accessing my primary duckdns url gives me a message:


    Welcome to our server The website is currently being setup under this address.
    For help and support, please contact: me@example.com



    When I try and access nextcloud, either via ip and :444 or my duckdns url, I get a message:



    I read through this thread and changed 'proxy_max_temp_file_size' 2048m to 1024m in my proxy prefs .conf file as it was giving me an error message.


    I also went through and tried both subfolder and subdomain methods, but both of them returned the same error message.


    It's safe to assume there's some misconfiguration in my config.php or my proxy confs subdomain / subfolder .conf files?


    Here are all three of them if anyone wouldn't mind taking a quick peek at them:


    1. config.php



    2. nextcloud.subdomain.conf



    3. nextcloud.subfolder.conf



    Is it bad to have both subdomain and subfolder conf files "activated" and without the .sample at the end. I've removed them occasionally, but haven't noticed any difference between having the opposing .conf file active while using the other method, but I guess it's worth a mention that both are currently active.


    Thanks for the help!

  • Nextcloud letsencrypt, port-forwarding and SSL cert difficulties.

    Zitat von Morlan

    Unlikely that you messed up configs on omv. Thats the advantage of docker, when you delete the static data and the containers your system is back to the previous state.
    Most of the time the error of the letsencrypt container is due to faulty port forwardings or your isp (not public available ipv4 address)

    Okay! Good to know going forwards, and it seems your are correct. I already went and reflashed and configured my OMV, and after following the process detailed in the how-to you supplied I arrived at the same result.



    Are the python SyntaxWarnings something to be worried about?


    Also, if it has to do with port forwarding, does this look alright or have I missed something fundamental?


    Here are my router forwarding settings.


    Or what would be some tools to troubleshoot the availability of the different ports?


    Thanks a ton!

  • Nextcloud letsencrypt, port-forwarding and SSL cert difficulties.


    Thanks for the extensive set of links! Good to know that I've been running outdated images and tutorials, will definitely save me some headscratching there.
    I followed the how-to but ended up once again receiving the same Cert-related error message when I ran the command "docker logs -f letsencrypt". I'll probably try and flash OMV anew and run it again to see if there might be issues with something related to my previous tinkering..


    Will definitely go through the links and climb the learning curve as best as I can, cheers!

  • Nextcloud letsencrypt, port-forwarding and SSL cert difficulties.

    Zitat von Morlan

    use this guide https://forum.openmediavault.o…g-OMV-and-docker-compose/

    Thanks for the link! Can't believe I missed that, looks just like what I need.


    I ran through the commands but was once again stumped by "docker logs -f letsencrypt" command, receiving the same Cert-related error message.
    I might just have to try flash OMV anew and try it without the possible previous adjustments still present and see if that helps..

  • Nextcloud letsencrypt, port-forwarding and SSL cert difficulties.

    Hi everybody!


    New to the OMV world, and I've been following TechnoDadLife's video series on getting OMV and Nextcloud running on a Raspberry pi 4.
    I had previously used a NextcloudPi setup, which worked straight away, but now I am getting some trouble with connecting remotely to my Nextcloud instance.


    I am able to get OMV 4 running on my Raspberry Pi 4, and it is set up just like in the TechnoDadLife video for now. I am also able to get MariaDB and Nextcloud working in Docker, with the lsioarmhf docker images. And using ip:444 I can log in and access my nextcloud in my local network just like I was able to previously.


    I run into trouble when I start configuring letsencrypt and duckDNS. Once I input "docker logs -f letsencrypt" in terminal, while "letsencrypt" is my running container's name, it first runs for a very long time (as the message in the prompt warns), but then it ends up spitting out an error message reading:


    "ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container"


    Following is the latest, complete error message with personal information redacted:



    Here are my duckdns and letsencrypt container configurations, as well as the port forwarding menu in my router.


    Link


    The only things I did differently versus the TDL videos are that I am running on OSX El Capitan, so I ssh in via terminal instead of shellinabox, that I use lsioarmhf images, and that instead of adding my-net into the "Extra arguments" section of the container config window, I connected the duckdns and letsencrypt containers to my-net in the configurations tab in docker window.


    I tried both the "Securely Login to Nextcloud Remotely on Openmediavault", and the "Free SSL Certificates with Letsencrypt on Openmediavault : Updated" videos instructions, which seemed to differ only as much as how the SUBDOMAINS environment variable is managed in the letsencrypt container. I now followed the more recent video, and simply used "cloud" as a subdomain for my "xxx.duckdns.org" domain that I have configured, as I figured it was pretty arbitrary, but I may be wrong.


    I used this tool and nmap in terminal to check my ports and set it to "Use Current IP", and found that port 80 is open, and port 443 is not. I am very new to any of this business with port forwarding or router configuration, so I am not sure if this is useful information or not. But I have gone through a multitude of threads here with similar issues and a common thread seems to be issues in port forwarding / port opening with the different routers people have at home, so I wonder if that's where my issue lies? If so, please advise on how to troubleshoot the issues.


    I have completely re-etched my OMV iso into the microsd on my Pi multiple times, and am now running a version in which the configuration steps are as 1:1 with the TDL videos as possible, with small variations pertaining to my Raspberry Pi and other (I think) simple differences.


    Sorry if it's a bit of a wall of text, but I wanted to try and provide as much info to be able to troubleshoot this issue concisely, and thanks in advance for the help, crawling through these forums has shown a really amazing community and amount of support to users starting out with their own NAS systems!