Posts by ragazzojp

    OMV is based on Debian. Since there are limitations when OMV is installed from its own installation media like putting data in the root partitions and so on, I always prefer to install a plain Debian stable from Debian official netinst, tune it a bit and then install OMV on top: there's a guide for that.

    This way you can configure the partitions and use them the way you want, keeping full control of the underlying system like /etc/fstab, /etc/crypttab that I use to encrypt /home and similar customization.

    It looks like it's not a problem of OMV. For who hasn't followed the GitHub technical discussion, it may happen on Firefox if you land on the OMV login page from another link. In that case, simply type the address of OMV (either IP or hostname) manually in the browser address bar and press enter, or click on the address bar with the address already there and press enter. This loads the page as not coming from another website and the login should work. Pressing F5 or refresh doesn't "unlock" it. You have to start a new navigation flow.

    Thanks, so you confirm it happens also when the address is an IP(+port). The explanation found so far is that "sometimes" FF doesn't realize that the connection is for the "same site" (it's a cookie setting) and it doesn't send cookies it is instead supposed to send when connecting to the "same site".

    Not yet, because I can reproduce the bug and I don't want to change my setup, restart browser, server or anything. We're still tracking the bug down, see GitHub link above. To confirm a theory, I would like to know the exact URL used to access the server, e.g. http://blabla, https://blabla.local,, ...

    Note also 5.5.22 doesn't contain any fix related to the problem compared to 5.5.21. The problem is very flacky, probability of encountering a false negative that makes you believe the problem is fixed is high.

    Not so fast please, the problem is not easily reproducible, I have it for example now after a week on 5.5.21.

    jac2598, what's the exact protocol and hostname you have in the browser?

    I think the "Run" command should execute the job script that cron executes and that contains the actual command, not the command directly. It's more elegant and safe and it would support multiple commands if these are written in the cron job script.

    Even without this refactoring, the command should be at least properly escaped.

    I tried and I was not able to replicate it, but I didn't dream it so I tried harder and I can replicate the problem now.

    If you try `whoami && pwd` you'll get `user` and `/`, but it should be `/home/user`. Indeed, if you try `pwd && whoami`you'll get `/` and `root`. It looks like `sudo` is applied only to the first part of the &&. This is because the resulting command is `sudo --user=user part1 && part2`, and the shell runs the 2nd part as root.

    There's the possibility of bypassing sudo for users able to define jobs, running arbitrary code as root.

    Last but not least, IMHO the working directory should be `$HOME` of user, not `/`.

    Hi, I'm new here, this is my first post.

    I'd like to report a problem. In OMV4, but I haven't tested 5, I have some cron jobs that are supposed to run as a given user. They do, when started by cron. However, when I test them pressing "Run" in the cron UI, they're run as root. I think this is dangerous, not to mention the jobs basically behaves differently than expected (different user id, different working dir).

    It's easy to test. Just create a new job, with command `whoami && pwd` and you'll find it out.