You just encrypt every single drive using LUKS. Lets say you have encrypted /dev/sdb and /dev/sdc. When unlocked, the drives show up as eg. /dev/dm-0 and /dev/dm-1. (You can still see /dev/sdb and /dev/sdc, but never try to access them in any way but LUKS!)
Now simply setup your btrfs filesystem like:
You may want to unlock them automatically by entering a passphrase on boot. I think thats the tricky part actually. You need to add your drives to /etc/crypttab file (It is like fstab but for encrypted volumes to be unlocked). When both of your drives use the same passphrase you can use keyscript=decrypt_keyctl to be prompted for the passphrase only once.
You will find specific steps on Google.
(Oh and you should test that on a virtual machine, and always have a backup!)
I'm wondering why 998. Is that a special user for your docker containers or plex in particular?
However, giving that user and/or group file and folder access should be all you have to do. It has actually nothing to do with docker. You should just familiarize yourself with unix permission management.
Try to assemble using --force. If that does not work you should probably just create new RAID and recover your last backup. And check health status of your drives.
Ach ich hab mich schon gewundert. Sorry!
Klar hat der da was zu suchen. Nämlich um sein Passwort zu ändern. Probier es halt einfach mal aus? Einloggen, Passwort ändern. Wo soll das Problem sein? Der hat da keine Möglichkeit iwas am Server zu pfuschen oder so..
macom Muss das extra zugelassen werden? Kann mich gar nicht erinnern
Einfach im Browser bei OMV anmelden und Passwort ändern.
No. You can use the Encryption Plugin for encryption of whole drives. Actually it can also manage encrypted partitions but you have to setup them manually.
File based encryption must be done manually. But maybe the best way for file based encryption is to do it client side anyway. (End-2-End)
You did something wrong.
i'm trying to understand why some time the files have wrong permissions and somethime not.
At least this is against my assumption that mounting may be the problem. But unless you provide complete information and answer questions, no one can help.
I don't know about SUSE, but on Ubuntu I've had similar problems due to the mounting. When using mount, you may read about mount options uid, gid, file_mode and dir_mode (https://linux.die.net/man/8/mount.cifs) in order to get matching permission pattern. On Windows it is simply working because it doesn't know anything about unix permissions.
Here is an example for a single user share on a multi user environment:
An easier way would be a gvfs mount, but I cannot use that since certain programs don't handle that properly.
So if I invite a family member/s ( each with their own Plex account ) as a Home User, and they want to access media that is stored on the NAS, would that stream go out via the internet ( use bandwidth ), or would the Home User view the media over the same based network ?
Edit: Sorry, misread. It goes over LAN if possible.
Only con that I see with each member having their own account, is that each user then has to pay for the device/s that they use ( android phones or tablets ), whereas with the Managed User setup, they all piggyback off the Home Owner account for using remote devices.
I think that is not true. The idea of Home users is that they don't have to pay anything if you already have a plex pass. You may verify that in Plex forums.
You can create managed users in Plex. That is the perfect solution if everything stays in one household. You have only 1 set of plex login data. If you want to grant access to a family member with an own plex account with its own login data, you can invite him or her as Home User.
In both cases that user is also able to use your plex pass functionality like hardware transcoding. If you invite someone just as friend, it is quite the same like home user but without plex pass functionality.
It is a Plex only thread. You can find more information in the Plex forum forums.plex.tv. Has nothing to do with OMV or shared folders.
I think that is already the automatic quick and dirty method if something went wrong. If your permissions are set properly and share is mounted correctly, that should not happen.
I'm starting this thread to get some input about your knowledge and experience on server security in general and maybe fail2ban in particular.
Since yesterday I am receiving lots of emails from my fail2ban service, banning IPs for invalid login attempts via sshd (SFTP). Forwarded/open ports on my modem/router are 443 (Used to access Plex and Nextcloud) and 200 (Used for SFTP access to my media folders).
Nextcloud and Plex are being behind a reverse proxy. Nextcloud is additionally secured with fail2ban and 2 factor auth. But port 443 seems to be clean. There are no suspicious entries in logs of Plex and Nextcloud.
SFTP service is secured with fail2ban and public key authentication. Password login is disabled.
So in the one hand I actually feel like having a quite secure setup. For home use at least. In the other hand I am no professional in that field and the intensity of ban notifications makes me a bit nervous. It is now more than 24 hrs that I receive a e-mail every 4-5 minutes about a new IP being banned after 5 attempts. RIPE information saying it's coming from different countries like Russia, China, USA,... My modem/router was turned off for about 6 hrs. in that time. When turned on again, ban mails restarted immediately. I mean, why would one just continue trying to get in even after the address was unreachable for several hours?
What are your thoughts, tips, own stories?
Permission issues have most likely nothing to do with OMV, but linux itself. You are free to abandon OMV but if you dont understand linux permissions, any linux based server will lead to such issues. And even windows servers are using a permission system. Quite the same point here.
If you want some help, you should provide more information. You say "accessing the new OMV NAS". There are lots of ways to access it. How are you accessing and what settings did you set exactly?
Edit: If you reinstall you just need to format the system drive. Maybe you should unplug data drives while installing just to prevent any accident. But I think this is not going to help as long as you don't understand what is wrong.
I am not absolutely certain but I think installing plain Debian first is even the only way to change partitioning and formatting of system disk. But I think you may find several threads in the forum where votdev answered that question.
About BTRFS vs ZFS. My plan was to just test both of them and so I started with BTRFS since you don't need any additional packages for that. It is automatically updated and improved with every kernel update, and that makes it very attractive for the system drive, as you said. Once I had tested everything, I was convinced of BTRFS and so I had no real need to try ZFS anymore. I think there are several reasons pro ZFS and there are several reasons pro BTRFS.
I think that RAID5/6 problem can occur in very very rare cases on power loss. I did quite intensive testing and was not able to reproduce that. Nevertheless, devs say it is still not fully fixed and stated as unstable. So one should actually listen to that and not use RAID5/6 in a productive environment. On the other hand, as far as I know, that problem can only occur on power loss. So you could probably use it productively with a UPS. Otherwise, ZFS might be better suited for you. (I thought you were using a RAID10. I misread that, sorry.)
That is exactly what I'm sitting on. To install OMV on an encrypted BTRFS Drive, the easiest (only?) way is to just install debian (without desktop) on LUKS encrypted BTRFS drive and then install OMV on it.
When setting up storage, you can just LUKS encrypt every single drive and then directly form a BTRFS Raid on the unlocked drives. You should not use mdadm for building Raid since you would loose BTRFS bit-rot protection. When U used to LUKS and BTRFS it is really easy and straightforward. I tested the setup process on a VM first, just to be safe in every step.
In order to auto-unlock the drives after boot, there are several different ways. I just used the same passphrase for all of my drives and activated the debian built-in crypttab script to auto unlock all the drives with a single passphrase prompt on bootup.
(Of course you should ALWAYS HAVE a BACKUP)
I can give you more detailed explanation if there are particular questions.
SFTP is no option?