Not understanding permissions.
Understanding how permissions work is the first step on the learning curve. This can help you: https://wiki.omv-extras.org/do…omv7:nas_permissions_omv7
Posts by chente
-
-
I think the port the daemon is listening (3493) should be added in the "How-to" in the "Configuration of a client" section.
Added, thanks.
-
Is this a link in /srv to the mountpoints what I`ve shown or is direct in /srv and there is a dependencies to the place on the SSD?
That's a mount point to one of your file systems.
-
-
Depends on permissions. If you pick "administrator - read/write, users - no access, other - no access", then non-root users won't even be able to access anything even if the subfolder is 777.
Hmm... I guess you're right, I've never tried doing that. Maybe I should warn about this on the wiki. Too many warnings and notes
I'm sorry if you thought I was insulting your system. I was not. I just don't like files in the compose file directory. Just my opinion. It doesn't mean anything has to change.
Not at all. If I gave you the impression I was offended, I wasn't. I just wanted to clarify this since you clearly stated that you don't agree with what's written on the wiki. The wiki is supposed to be there to help you when users ask questions, so I'd like you to be comfortable with what's there. Every time I make a change there, I try to ask you if you're okay with it; I think you've noticed.
Anyway, if something needs to be changed, we can discuss it. Depending on the change, it may be more or less laborious to adapt the wiki to what you'd like.
I'm not sure how selecting a shared folder implies it is on a conventional hard drive. You can pick any storage for a shared folder. As usual, I am in the minority and none of my containers use a ton of space. Every container I run is 100% on nvme.
Well, I'm just thinking about the most common systems where there are several conventional hard drives and a fast drive (NVME or SSD) for Docker and KVM. As we've already mentioned, there are many possibilities. A system with a single 4TB NVME drive wouldn't raise these concerns.
I just need to stay away from these docker threads. People should follow the guide. Me posting just confuses people.
If you prefer, we can continue discussing this privately, as we've done so many times. I responded to your post here because it was a direct reference to me, as I wrote that document. No problem.
-
If you go down that road, it is possible that all volumes have sensitive data. My point is that everything in the compose file directories was meant to be plugin generated content and that is why owner/permissions was enforced. Anything in the compose file directory should not be container generated since the plugin enforced permissions on the parent directory may not be correct.
It works if you use subfolders as designed in the wiki. You're right that it will fail if you place files directly into that folder. That's what happened to the OP.
It wasn't designed to be something that could be used by all systems. Since having many shared folder selections on the Settings tab doesn't scale well, I just created one. I don't think using global variables is bad. It was added so people could do whatever they want.
We agree on that. I just tried to present a universal method that works on any system.
I'm not saying your system is wrong. I don't think I have ever looked at Zoki's guide. I was only saying to not put container/user generated files in the compose file directory. I was suggesting that it would be easier to use the CHANGE_TO_COMPOSE_DATA_PATH since I use it for everything on my system and the example compose files I create. I don't care where anyone puts any files but the plugin will continue to maintain the owner/permissions of the compose file directory since it is creating the directory. So, if the container can't handle the permission change, don't put container or user generated files in it.
Using the CHANGE_TO_COMPOSE_PATH variable for everything implies, for example, that the persistent data will live on a conventional hard drive. This may not be convenient if you need access to that persistent data to be as fast as possible, as might be the case with a Jellyfin or Plex database. In this case, it's better to use an NVME drive or at least an SSD. The data will reside on a slower, larger-capacity conventional hard drive.
-
Why are you putting data in the compose file directory? Those directories are supposed to be more locked down since there is often passwords involved. The whole point of the CHANGE_TO_COMPOSE_DATA_PATH variable is to use the data shared folder for volume storage. The plugin doesn't change that ownership.
I believe I should protect persistent data and compose files equally. Both contain sensitive data, passwords, etc.
Well, I didn't write it but I disagree with that. My opinion though.
There are infinite ways to configure containers. The Docker in OMV document describes one that works and tries to be as educational as possible for beginners to understand. It also works for any hardware configuration.
The CHANGE_TO_COMPOSE_DATA_PATH variable can be useful in some simple systems, but not all. The fact that there is only one variable is somewhat limiting. In basic systems with a single file system, it will work without problems, but if there are multiple file systems with data, the user would have to group them to use that variable in all containers, for example with mergerfs, and that would complicate things. Alternatively, it could be combined with other methods to complete the configurations. That's why I left it optional in the document, focusing instead on the use of global variables to define paths (or symbolic links, alternatively). The user is given the option to use this variable anyway, and its use and what it does are explained, of course.
In my case, for example, and I'm sure it's the case for many users as well, documents, media files, and Docker and KVM files live on different file systems. And it doesn't seem reasonable to me to complicate my configuration to use that variable in all containers by grouping those file systems together if there are other, simpler methods.
Grouping persistent data folders in the appdata folder seemed like the best way to keep things simple when I started using this plugin. I actually copied the idea from the system Zoki used, which he posted a long time ago on the forum. This system was a perfect fit for the plugin, so I did it that way, and it's worked for me for years without any issues. Therefore, I also wrote the wiki document this way.
This has been mentioned previously in the forum, and your response was that you didn't want to complicate the plugin with additional variables to do the same thing this one already does. It would be easier to use this variable if there were at least three (at least in my case), but this isn't definitive; there may be other cases. Using global environment variables or symlinks is a universal solution.
this sounds like what I did wrong.
The documentation explains how to do this correctly in several places. I've added a warning about this possible permissions change if done incorrectly. I hope this helps others.
omv7:docker_in_omv [omv-extras.org]
QuoteMake sure to create subfolders within each appdata folder for each container folder.
Don't do this: - /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin:/config
If you do this, the persistent data in the config folder will be mixed with the plugin's Docker files, and permissions could change without warning.
Do this: - /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin/config:/config
This way, the permissions will remain the same as the container creates them.
-
Display More
Tx for the info.
I think my issue is that having cut my teeth on SCO Unix way back in the day (I did say I was old fashioned), before I went to Windows and then appliances, I really don't want to go back >35y to /dev/this and /dev/that. Plus I'm leery of learning more cmdline, only to hose myself when I misplace a character.Thus I was sold on OMV for this https://wiki.omv-extras.org/doku.php?id=omv7:new_user_guide
"One of the ambitions of the openmediavault project is to make advanced NAS technologies and features available to inexperienced users in an easy to use WEB GUI, thereby making it possible for people, without extensive knowledge of Linux, to gain easy access to advanced technologies."
I find it a bit surprising that it seems that one has to delve under the hood to check that (IMO) core functionality of data verification is working.I'll post a request on Github.
If you're looking for something similar to Windows, you won't find it in OMV. OMV provides a GUI where you can manage the system, and what that quote says is true. But, likewise, you'll occasionally need to type a command in the CLI. If you have a problem and ask a question on the forum, it's very likely that the answer will ask for the output of a command. So, to use OMV, you need a minimum knowledge of the CLI. You don't need to be an expert. But you should at least be able to type a command if necessary.
Keep in mind that OpenMediaVault isn't commercial software with a team of well-paid developers behind it. On the contrary, it's free software developed by a few people in their spare time. So, you can't expect fancy stuff. If you're looking for a NAS operating system where you just need to press buttons, you might be interested in a commercial system like QNAP or Synology, something closer to Windows. With their advantages and disadvantages (many disadvantages, in my opinion).
As you'll understand, I'm biased, and I defend OMV above any other system. The freedom that OMV gives me to do what I want on the hardware I want was never offered to me by QNAP or Synology in the 10 years I used them. I wouldn't trade OMV for anything. But if it's not what you're looking for, don't worry; there are other alternatives on the market.
If you decide to stick with OMV, you should try to overcome that initial learning curve to feel a little more comfortable. Install Putty and access the command line. Experiment a little.
You only need to dig under the hood if you want to know how things work. But if your NAS use is going to be basic, you don't need to know that.
Good luck with your decision, and, as you know, if you have questions or need help, we're here to help you (free of charge). You won't find that with either QNAP or Synology.
-
If I had wanted to keep it, I probably would have ended up exporting the pool. And then I would have manually removed those file systems from the database. Then I would have applied the appropriate salt commands. Issue solved.
But I think it would be nice if there was a proper way to do it from the GUI. A novice user wouldn't know how to do what I just described.
In my opinion, the Export button should remove the file systems from the OMV database at the same time as exporting the pool, provided they are not referenced, of course.
And going even further, it would be desirable that if those file systems are referenced, the Export button would issue a warning and the export would not be performed.
-
There's a "zpool destroy ..." command to zap a pool. Just do a "zpool export.." to re-use elsewhere, but it won't export while it is busy/referenced.
Yes, I know I can do this from the CLI.
The question is how to do it in the GUI without leaving "missing" file systems in the OMV database. In this case, I didn't need to keep the pool, so I destroyed it. But it would be good to know how to do this if I need to keep the pool in the future and not leave a trace in the OMV database.
There were no references to those file systems when I exported it, however, "missing" file systems remained in the storage tab.
-
the browser loses connection to the OMV web UI mid update
Are you publishing the OMV GUI online? If so, you shouldn't; you can be hacked. I would use a VPN to remotely access the GUI.
-
hello bro I'm not that so good on linux can you send me a tutorial or something do you make videos tutorials about those things ?
To install OMV, do the following:
- Download the OMV image from the link I provided. The stable version.
- Burn this image to a USB flash drive. For example with Balena Etcher. https://etcher.balena.io/
- Connect the USB flash drive to the server and a second USB flash drive. On the second, you'll install OMV from the first. 16 or 32GB is enough.
- Boot the server and access the BIOS. I don't know how to access the Orico BIOS; you'll have to look at the Orico documentation or search online.
- In the BIOS, select the USB flash drive containing OMV as the boot drive. Save and accept.
- After that, you'll be installing OMV. Just accept the options and answer the questions. Make sure to select the second USB flash drive as the installation destination instead of the Orico's internal drive. That way, you can return to the Orico operating system if you decide OMV isn't for you.
-
The short question is: How do I unmount a ZFS pool in the GUI without deleting it?
The long story is:
Yesterday I replaced the mirrored ZFS pool on my server with a new RaidZ1 pool with new hard drives. When I got to the point of unmounting the old pool, I didn't know how to do it. I clicked the export button in the GUI, and the file systems appeared as "missing" in the storage tab. So I reimported the pool and deleted the file systems one by one in the GUI, finally deleting the pool. Everything worked; the file systems also disappeared from the storage tab.
In my case, it wasn't important whether or not to delete the old pool, since I'm going to use the hard drives from the old pool on the backup server with a different file system. But I'm wondering how I would have done it if I had wanted to unmount the old pool instead of deleting it to use it on another server.
-
bro please could you help me please
You're using Orico's proprietary software. The first step is to remove that software and install OpenMediaVault. To do so, follow the steps in post #1 of this thread.
You can download openmediavault here. https://www.openmediavault.org/download.html
Then, install Plex on Docker following this document. https://wiki.omv-extras.org/doku.php?id=omv7:docker_in_omv
-
-
hello please i just buy the orico metabox pro (HS500 Pro) please can anyone help me install plex on it or make the HDMI work been searching for tutorials for a week and I've not been able to find a solution the system backup it's nice not perfect but wark, apart of that the system CYberData OS doesn't have an app center
Of course, it's easy. Install OMV and then install Plex on Docker.
-
Read here:
-
You're using the official Nextcloud image. It won't be easy to get help for that image on this forum.
You have a guide in the guides section for the Linuxserver container, and you have a Nextcloud AIO implementation on the wiki. If you choose one of those two, it will be easier for someone to help you with Nextcloud.
-
Have you used the same power supply both times?
-
