Beiträge von stinkycheese

Hi there

I landed here after something kind of similar happened to my in-progress OMV7 bare-bones build (on an RPi5 / 8Gb).

I'd been building this system over several weeks without any problem, then this evening I noticed that I quite suddenly could no longer log in as admin. It's not a browser problem (I have emptied the cache, used incognito mode and even different browsers) and it's not a password problem (I can change it with omv-firstaid no problem). It isn't rejecting the admin credentials. it's just not accepting them.

After reading a bunch of old posts about similar issues, I've also tried these commands, but they made no difference:

sudo omv-salt deploy run nginx phpfpm

sudo systemctl restart nginx

sudo systemctl restart php8.2-fpm

Also:

$ id admin

uid=995(admin) gid=100(users) groups=100(users),988(openmediavault-admin)

Update:

I can now confirm that this behaviour continues unchanged when I attempt to log in:

1. via a completely different device; and
2. using a different account in the openmediavault-admin group.

I'd love to know if anyone has a genuine fix for this! I'm not keen on investing the time to start creating my OMV7 from scratch (again), as I wonder if the same thing will lock me out again.

Postscript... 3 days later
It turns out one of the expert pieces of advice offered elsewhere in this forum was right on the money: my 8Gb micro-SD boot medium was losing brain cells at considerable pace. Have just switched to new 32 Gb cards (yeah, could've gone bigger, but it makes for huge .img backups that are mostly zeroes).

Thanks a bunch

Neil

Zitat von ryecoaaron

You are going to be waiting a long time then. There are no dragons and this isn't a compose plugin problem. This is a "docker-compose complaining about the your portainer volume" issue. I would guess you still have portainer running. If you insist on continuing to use portainer, I would recommend you exporting your portainer data, removing the portainer container and volume, then create a new portainer compose in the compose plugin, and import your data.

The gulf between my level of knowledge and your own makes me appreciate your incredible dedication & commitment to everything OMV - thanks!

neil

Zitat von chente

If the only problem is that the examples do not appear, copy the content below in a new File and implement it, the result will be the same.

Code

---
version: "3"
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - portainer-data:/data
    ports:
      - 9000:9000
volumes:
  portainer-data:
    external: true
    name: portainer_data

Alles anzeigen

And yet it continues to object every time:

Portainer.yml is invalid because:

volumes.portainer-data value Additional properties are not allowed ('name' was unexpected)

I understand this compose plugin change is in fact very simple and works 100% of the time, but until it's even simpler and works more than 100% of the time, I'm rolling back to 48 hours ago & going to steer clear of this update until the dragons have cleared out,

Zitat von ryecoaaron

But it isn't a substantial change. It is moving components from one plugin to another. I will admit that we need to improve the docs since people are having issues but I struggle to understand the noob thinking well enough to write those docs.

I would love to know what you did because I am guessing you clicked the Reinstall docker button? I had a note that it was only needed if docker was not already installed. I bolded that note. Otherwise, all of these changes would NOT touch your existing docker containers and moving portainer to docker-compose control would only take down portainer and NOT other containers.

If you use the portainer-omvextras example as I mentioned in the first post, your portainer should just come back and you can start your stacks again. nothing should be lost unless you did something else.

Duly noted - thanks for taking the time to reply.

Here's exactly what I did:

1. ssh'd: docker container stop portainer
2. ssh'd: docker container rm portainer
3. Clicked "add example" on the Files tab of the compose plugin, hoping to select the portainer-omvextras example, as instructed - but there no items in the drop-down list.
4. Refreshed browser cache, tried a different browser, rebooted everything, lit a candle - still couldn't see any Examples in that drop-down list.
5. Restored OMV from a recent backup & all working as it did prior to update.
6. Updated OMV-extras again with a somewhat better result - I can now see the examples and select one.
7. Unfortunately, I now get stuck at a persistent error objecting to something in the recommended example's YAML:
   
   "volumes.portainer-data value Additional properties are not allowed ('name' was unexpected
   
   I have no idea how to get past this, but I'm sure I will.

I don't want to sound unappreciative of the wonderful work & dedication put in by everyone associated with OMV: devs, admins, moderators, writers - thank you all for your amazing efforts.

However... this seems like a disproportionately casual announcement and lightweight transition documentation for what appears to potentially be a most substantial change.

Substantial enough for everything in my Docker-Land to be ticking along perfectly before the OMV-extras update, then 100% scorched earth after said update.

And, regrettably, it will remain scorched earth until I can familiarise myself with doing everything via the new Docker Compose plug-in that I used to do via Portainer. For someone like me who has not coded from infancy, some things are not universally self-explanatory.

I would have been most grateful for:

1. a bit more critical information up-front, along the lines of "your present Portainer environment will cease to operate, at least temporarily".
2. somewhat more than the 3 lines of instructions featuring the words "you should be able to use...".

I will be even more grateful if my most recent OMV system backup gets my Docker set-up working again.

Zitat von chente

Happy to help.

When you do it you will see that it is much easier to do it than to explain it. You'll be done in 5 minutes.

And, as I said, using ACL permissions doesn't make any sense if it's not a very special case. You don't need them, you'll just make your server more complicated for no reason.

WOW!!!!!

Everything you said was absolutely on the money, Chente. Once I understood the basic principles from your explanation, it took me less than 5 minutes to configure my shares exactly as I needed, without the use of ACL or Samba options (with the exception of disabling "browseable" for one specific share).

In any other situation, I'd say it was embarrassingly simple & that I had wasted quite a few hours "barking up the wrong tree" - but there's nothing embarrassing about learning how to make anything simpler!

Thanks again for your guidance - I am very grateful for it & the time you put into it.

Warmest regards

Neil

Thanks very much - it is so kind & helpful of you to take the time to explain this better way of doing things. This is a terrific community to be a part of.

I'll be spending my Saturday afternoon experimenting with your suggested approach.

I am most grateful!!!

Neil

Zitat von chente

In the vast majority of cases it can be resolved with the standard linux permissions. I would try to stick to that.

I have never needed ACL, I have always been able to solve all situations. ACL is an unnecessary headache.

Thanks for your insight on this, chente - as I mentioned, Windows is how I was "brought up".

But now that I'm rebuilding my system, it's probably a great time for me to expand my skills. And I LOVE simplicity.

Perhaps you could give me a tiny kickstart with a simple (I hope!) example. 🤞

Let's say I have an Ext4 FS that will only be accessed as an SMB share through Windows as follows:

• User A needs Read/Write/Execute access.
• User B needs Read access.
• User C has no access.

(SMB is my go-to share format for this Windows-only (family) environment - but I'd be happy to hear any suggestions you may have for something different that OMV supports.)

I know how to do this via ACL, but I don't have any experience using permissions only.

With a bit of a steer, I should be able to figure the rest out solo!

Thanks very much for your help

Neil

Zitat von chente

I can't answer your question because I don't know the answer. But may I ask why do you need ACL permissions?

For granular control over who can access what, and how.

Someone else solved the problem for me... embarrassingly simple!

Zitat von synapsensau

NTFS is a file system from the Windows world and therefore cannot handle the Linux ACL. Use a Linux file system (ext4, btrfs, xfs.....) so that the Linux ACL takes effect again.

Is possible to use NTFS drives?

Thanks for your stunningly simple & completely logical response.

Duh... that should've been obvious to me, so I'm a bit embarrassed. 😲 (I blame it on my Windows upbringing.)

Until it died a few weeks ago, the main partition on my previous NAS drive was absolutely NTFS. But it has been a few years since I set that up, so I must conclude that I never had access to the ACL config for it - which wasn't a problem... until I had to set up the replacement drive recently.

Now I guess I'll discover how much I don't know about the Linux ACL!

Cheers

Neil

Hi everyone

I know this problem (or one much like it) has been encountered by others - because I've already read several posts about it & no obvious solutions have emerged.

I've just finished a brand new OMV install, at the end of which I added a new 10Tb WD drive (USB connection into RPi4). I have created and mounted a 6Tb partition (NTFS), but cannot access its ACL configuration - the ACL button is grayed out.

Some additional details to inform replies / suggestions:

1. This file system is not yet referenced (as attached screenie shows, there is no check mark there); configuring its ACL is, 100% literally, the first operation I have attempted to perform on it.
2. I have given the relevant user read/write perms in shared folder permissions.
3. The reason I rebuilt my whole system is because I encountered exactly this problem with my previous OMV setup - so I figured (wrongly) the quickest way to work around it was a "scorched earth" rebuild.
4. I have also created a couple of smaller partitions (1 Tb or less) with Ext4 file systems and been able to configure their shared folder ACLs exactly as expected.

I don't really have a usable system if I can't control access to the main data partition & would be delighted if someone could explain the problem to me and beyond grateful for a workaround (e.g. manually adding something in config.xml?).

Cheers

Neil

I've been running with LUKS encryption on one partition for several years, first on a RPi3 and more recently on a RPi4.

If there is a performance hit, I've never noticed it - and I am big on measuring this kinda stuff.

I think I have it sorted, @macom.

A few searches made it clear that official docker images are usually not ARM-friendly. There are plenty of supposed solutions and even some images that will work on most of the RPi family.

The solution that worked for me can be found here - it's a very concise, straightforward and well-presented guide, but I had to research two resulting errors to find the missing piece of the puzzle, which slots in before the final step:

sudo apt install -y python-all-dev python-wheel

Then finish it up with:

sudo pip install docker-compose

And surprise, surprise: my original docker-compose.yml worked perfectly first time!

docker@phewtus:~/nextcloud$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
linuxserver/letsencrypt latest 40d5e2dbd8f2 16 hours ago 224MB
linuxserver/nextcloud latest 3cc1ef5127b9 26 hours ago 264MB
linuxserver/mariadb latest db16f0c83902 4 days ago 278MB
docker/compose 1.24.1 9bd979cced2e 4 months ago 67.9MB
arm32v7/hello-world latest 618e43431df9 9 months ago 1.64kB

Thanks for your help with this one - now that I've got it working, I'm sure I'll be back before long with more questions on getting it to work as I want it to!

Hi again, @macom

Here ya go... I hope this helps:

boss@phewtus:~/bin$ dpkg -l | grep docker
ii docker-ce 5:19.03.4~3-0~debian-stretch armhf Docker: the open-source application container engine
ii docker-ce-cli 5:19.03.4~3-0~debian-stretch armhf Docker CLI: the open-source application container engine
ii docker-compose 1.8.0-2 all Punctual, lightweight development environments using Docker
ii openmediavault-docker-gui 4.1.5 all OpenMediaVault plugin for Docker
ii python-docker 1.9.0-1 all Python wrapper to access docker.io's control socket
ii python-dockerpty 0.4.1-1 all Pseudo-tty handler for docker Python client (Python 2.x)

apt-get install docker-compose seems to complete normally - I've been installing it exactly per the guide .

The method I attempted in my previous post came close to finishing, then ground to a halt with some impenetrable messages.

I found another site that published a recent guide for installing docker & compose on a Pi - I'll give that a try tomorrow.

Though I'm pretty new to Docker, I'm starting to get the impression that docker-compose is simply not ARM-compatible - I don't know how authoritative this guy's blog is, but this may sum it up:

"... docker-compose is not (yet) available for Raspberry Pi or any other ARM architecture."

According to his most recent update on the subject in March 2019, make docker-compose work on a Pi still requires some geek ninja skills.

My attempt at the easy way ("pip install docker-compose") died prematurely, so I decided to follow his rather more complex manual method by blindly copying & pasting each command. My little Pi has been valiantly churning away for about 45 mins now, fortunately with abundant screen output (or, as I like to call it, "proof of life").

I think it has a while to go, but I'll report back tomorrow on the final result. I'll be pleasantly surprised if I don't have to restore from the system image I made before I began.

Thanks for your prompt responses, @Morlan & @KM0201.

The errors you both called out in my attached .yml file weren't in my 'live' file - they were just cross-eyed editing glitches I made when removing my personal details from the file before uploading it. I have just reviewed the live file once more and can confirm that it doesn't have those, er, features - so I'm still getting the same error. Since your responses, I've tried recreating docker-compose.yml from the guide, but the result is identical.

As for the location of the .yml, @Morlan - it is in /home/docker1/nextcloud and that is where I'm executing it from.

But your comment on compatibility had me wondering about a potential issue with the current build of docker-compose:

Before trying this installation guide, I spent quite a few hours following different instructions, which required me to pull the 'latest'-tagged docker-compose image through OMV's Docker UI. It repeatedly did nothing when I specified "latest" as the tag or left it blank - the only way I could pull it successfully was by specifying the tag "1.24.1" in the dialog (I've attached screenies to illustrate). I understand this may not be typical.

Anyhoo - thanks for your kind efforts & input - and apologies again for the sloppy errors along the way.

Cheerio

neil

My apologies to all for the double triple post - "finger trouble"! it won't happen again.

Howdy all

Many thanks to @macom for this outstanding & very detailed guide - I look forward to reaching to the end of it, but...

First of all: I'm running on a Raspberry Pi3+ - which is ARM architecture.

I have followed each step precisely, including making all the necessary changes to docker-compose.yml where instructed - but unfortunately, I receive this error each time I try to execute it (I've pasted the output in full for clarity):

docker@phewtus:~$ docker-compose up -d
Unable to find image 'docker/compose:1.24.1' locally
1.24.1: Pulling from docker/compose
c87736221ed0: Pull complete
ba1ee912e9a7: Pull complete
2df7dacacdeb: Pull complete
6037f24be055: Pull complete
Digest: sha256:8616a861a5c769b7fe633625a4d5a4f76ae5a54d1d04874dcef827644c136684
Status: Downloaded newer image for docker/compose:1.24.1
standard_init_linux.go:211: exec user process caused "exec format error"
failed to resize tty, using default size

There is no sign of anything have executed, as there is not even an empty "nextcloud" folder created.

If I rerun it, it just skips the image pull (of course) and spits out exactly the same error.

I've spent a fair amount of time trying to resolve this (gotta move beyond Beginner, right ?), and the most plausible explanation I've found is that Docker can't start the build because the binary in the images is incompatible with the environment in the container, i.e. the repo images are for AMD64 hardware, not the RPi's ARM.

In case anyone with greater knowledge wishes to take a look, I've attached my .yml file (minus details like my email address).

I'd be very grateful for expert advice on this, because it is driving me crazy & I think I've hit a brick wall on this. (and yes, switching to AMD64 hardware is an option, but only if all else fails).

Many thanks in advance

neil