Posts by KM0201

    post the output of:

    id your_username


    ls -l /path/to/share

    obviously your_username is you omv username, and /path/to/share is whatever path you're having issues with.

    After we setup OMV5 over Debian, is the user account (created during setup) useful for anything? Does the default admin account need to be the main admin account? Can it be deleted?

    I would keep a user account, but that's juts me. If you want to delete it, and then add one via the webUI, you can do that as well

    You can give users admin privileges, but I don't think you can delete the admin account (I'm not sure why anyone would want to do either, but it comes up constantly for some reason)

    KM0201, Tried that command but didnt work. I'm not sure how my permissions have ended up like that! I did have a plugin installed that allowed users to create folders within root, I've unistalled that now.

    Soma, this is what I get when i run that command:

    root@raspberrypi:/# ls -l /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/media/nextcloud
    total 4
    drwxrwxrwx 1 root root 4096 Jun 15 09:21 data

    His command is going to show the same as mine, that's not in debate. It's clearly inheriting permissions from the root directory of the drive.

    My hope was the chmod command would change the nextcloud folder, but clearly it didn't. When I'm talking about the root directory, I don't mean root directory of your OS drive (which I think is what that plugin does), I mean the root of the data drive.

    What is the output of

    ls -l /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/

    That is probably going to shoot the same permissions as everything else, thus affecting the permissions of everything under it.

    I don't see where the difference in the path matters, since it is complaining about the data drive (which he has marked to /media/nextcloud/data)

    His permissions are still completely out of whack (.Nextcloud is my data directory)

    It appears your drives root directory is set to read/write by everyone. This is a terrible practice, IMO.. but that is another story. I'm assuming when you create the directory /media/nextcloud/data, it is inheriting the permissions of the root directory, thus causing your error....

    You can *TRY* this, but I'm not sure you'll have much luck, given the permissions that are above the nextcloud folder..... it might fix the problem.. but there's a good chance at some point the permissions will be overwritten by the root directory again.

    You really need to properly set permissions on your drive

    chmod -R 0770 /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/media/nextcloud/data



    • Your data directory is readable by other users

      Please change the permissions to 0770 so that the directory cannot be listed by other users.

    Nextcloud – a safe home for all your data

    The command:

    ls -l /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/media/nextcloud/data

    Outputs this:

    root@raspberrypi:/# ls -l /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/media/nextcloud/data
    total 8
    drwxrwxrwx 1 root root 0 Jun 15 09:21 Craig
    drwxrwxrwx 1 root root 0 Jun 15 09:21 appdata_ocenhlql2o57
    -rwxrwxrwx 1 root root 0 Jun 15 09:21 index.html
    -rwxrwxrwx 1 root root 7738 Jun 15 09:21 nextcloud.log

    I created the docker-compose file using Somas example above after deleting all directories that I could find from my multiple failed installs. ;(

    Also, please post the output of this command..

    ls -l /srv/dev-disk-by-uuid-20A00CCAA00CA7FC/media/nextcloud/data

    Did you reinstall w/ the old data directory? I'm assuming so. Unless you have a reason not to, I would delete all associated directories , then run the stack/docker-compose file, and let it create the directories. If you're gonna start over, really start over

    I made this change and it worked! I don't quite understand what the implications are to deleting the files that ryecoaaron mentions in his post though. I assume that the change was never integrated into OMV-extras though.

    Oh I have no doubt what he said worked... that wasn't the question. Even he mentioned though there's a limitation as it's not going to auto update if drives are removed/added... the delay script doesn't have that limitation.

    Well the nextcloud container looks OK, so I have no idea what could be wrong.

    Is your nextcloud database container throwing any log errors?

    I've never personally had a database error w/ nextcloud... so this would surprise me unless you're doing something weird.

    post the output of (you might need to edit out your url)... but if it's a config issue, you should get a repeated error showing which line the error is on. You had to change the config file during the setup of the container.. your edits are in there.

    docker logs -f nextcloud

    (use Cntrl C to exit the log)

    Maybe I'm totally off base, but i seem to remember reading somewhere that duckdns did not allow subfolders (I've always used subdomains, so I never put it to the test)

    Maybe you installed omv-extras/docker before this was implemented. But you can retrofit it as described in the post.


    I'd never seen that solution, I always just suggested the delay script you posted a couple years ago (and have always heard back that it worked perfectly). I'm assuming this would work fine, but I think the delay script might be a more permanent solution given it doesn't self update... Especially since we are talking Pi's and other SBC's which may have drives getting moved around, etc.

    Choices... 1 isn't enough, 2 is to many... :)

    I was curious about that too. Your trusted_ domains and trusted _proxies are identical.

    That's how I've always set it up, never referenced the swag container (although I know some do). The trusted proxy, is because if you don't do that, it will throw an "error" under basic settings in Nextcloud (or at least I always do, maybe because I don't reference swag, that is why). It's really not an error, as if you actually read it it's confirming the proxy is working... I could remove my IP address, as I disable local access anyway, but usually when I add this line I just copy/paste my trusted domains. The IP address is just so if you want to enable local access without getting a security warning.... Otherwise you can just delete that line. I disable local access from my stack/docker-compose... so I should probably delete it anyway, I just never have.

    RE: Nextcloud Bad Gateway