Jump to content

RiffSphere

Members
 View Profile  See their activity

  • Posts

    8

  • Joined

  • Last visited

 Content Type 

Everything posted by RiffSphere

  1. RiffSphere
    I could see that, but disagree. They are generally not starters. They would generally want speed and more than 1data+1parity in the cache pool. At this point they still are forced to have an array wasting 25% of their allowed disks. They are also the opposite of a starter. If we gonna have changed licenses anyway, nothing stopping them to add "docker only" (removing array support) and "archive only" (removing docker/vm support), hidden behind "more options". The starter name does not match the audience, and is imo too limited to showcase the security and flexibility of the system to real starters. PS: I'm not hating on the concept, we all like free things, but free for life is not sustainable, and I'm surprised they have done it for this long. But the model has to be right, something 6-12-unlimited disks does, but 4-unlimited does not. Most of my servers surpass 4 (raid1 cache, dual parity to never have to worry when adding disks, data disk and download cache) disks, it's hard to convince starters to use a higher end version from the start, it's easier to force them into an unsecure system with unprotected cache they'll destroy in no time with downloads and a single parity array. Until the negative publicity about yet another data loss incident.
  2. RiffSphere
    I don't get the step down to 4 devices for the starter edition. In my opinion, 99% of unraid boxes need 2 things: - A cache pool. Without it, apps (like plex browsing) feel slow, and many people wont max out their network speed when writing files. And I already hate there isn't a harder push to make this a parity protected pool, as it's not protected by the array: If the disk fails, all your apps crash, and your recent data is gone (seeing backup will probably align with mover). This uses 2 out of the 4 disks starter offers. - The array, the unique thing unraid has over any other system I've seen: realtime parity protection with almost instant expandability with any size (up to parity) disk. The starter limit of 4 will either lock people out from experiencing the full power of the array, or "force" an insecure cache setup. Even more so if they follow the "plug in your usb disk with unassigned devices and use krusader to move your data to the array" suggestion given to new users. I really hope this number will get reviewed and changed, a clearer message/warning about single disk cache pools will be added, a smarter mover (so it can start moving files when low server/disk load instead of time based) will be added and a (smart, as close to real time as possible) appdata backup is implemented. It's the starters that need the most help keeping their data secure, since they are new. If you are going to "force" them in a bad security pool setup, you better account for that to prevent data loss.
  3. RiffSphere
    - ANY container path of /config is automatically adjusted to be /defaultAppDataPath/NameOfContainer That's probably why the ibracorp's jellyseer is not getting changed, it's mapped to /app/config. I just found it strange that, in my limited testing with just the containers I was installing, the issue would happen when the appdata path in the template was empty, and not if it had defaults in it. But I guess it's more related to good templates using /config (and leaving it empty) and bad templates using another path (and have a default setting)? - However, that wasn't the main part of my bug report. Following are the defaults for the same container (linuxserver sonarr), first one with exclusive share, second without exclusive share (all settings the same, just added array as secondary storage for the non exclusive share): https://imgur.com/Nenld06 https://imgur.com/jfR2Kao (ignore the extra -1 at the end, I saved the config to check the template when doing the exclusive share) As far as I know, it shouldn't use "/mnt/appdatapool/appdata/[container] for appdata, but /mnt/user/appdata/[container]. To be clear, both do point to the same location: https://imgur.com/a/hKJ4oaI, so I think it resolves the symlink instead of using it as the path.
  4. RiffSphere
    I seem to have indeed read over that big info box, my bad 🤐 However, that same box states "Files on other disks that are in a folder corresponding to the share name will still show up under that share for read purposes.", and I can change and delete the files on the excluded disk, and they are not read actions. It also doesn't state that the free space of that disk will be added to the share free space, even though it's not writable. The docs also state that " If no drives are specified under these settings then all drives allowed under Settings > Global Share settings are allowed", with not option to not configure the included disks. Bottom line is, the include and exclude is really unclear, and the docs don't make it clearer. I have a feeling that, with the changes to shares in 6.12, some settings were changed, with the docs not being updated. I personally don't agree that files in a folder matching the share name on an excluded disk should show up, but if that's by design, I guess it's not a bug. If there is a reason to do so, I'm also interested in knowing why. As for the other points, I still consider them bugs, as this imo illogical behavior is not documented (as far as I read, but seems I do miss some obvious things, so I apologize for that) as a designed feature.
  5. RiffSphere
    You might call it normal, but that's not what I expect from an "excluded" disk. If I exclude something, I don't want it in there. Again, I understand that include is handled over exclude, but I don't have the option for "all but excluded", that would fix the issue. (I tried to make it a general bug report, with examples of how and why I expected things to behave differently, but it was made after seeing and testing this reddit post: The user did create a share, then for some reason decided to exclude all his disks, only to get errors that there is no space left while everything indicates there is, with no errors or warnings about a misconfiguration). Edit: Also, from what I read in the docs (again, other than it technically being included by the "all") at https://docs.unraid.net/unraid-os/manual/shares/user-shares/#included-or-excluded-disks, it is not normal: "Specify the disks to exclude here. For example, set the excluded disk(s) to "disk1,disk2" to restrict a share from using disk1 and disk2."
  6. RiffSphere
    Say I have 3 disks now. I make a share (lets say "backup") that I want to only include disk 1. This is easy, include disk 1. Now I make another share (say "media") that I want to include all but disk 1. I could indeed set included disks to disk 2 and disk 3. However, in 3 months my disks are full, and I add disk 4. Now I have to remember to include disk 4 in my share, or it wont be used. The other option is to not set any included disks, and it will default to "all". If I now add disk 1 to excluded, it does indeed work as expected: every disk that is not disk 1, current or future disks, will be in the media share. The issue is: If for some reason disk 1 has a "media" folder in it's root (because I did not include it when I originally included the share for example, or because I have a script that does output to that folder while it shouldn't), the free space of disk 1 is being included as free space for the share. If there are files or folders in disk1/media, those files and folders can be opened, edited and removed. The only thing I can't do is create new files on disk1. So the share would show empty space left if all other disks are full, but still report there is no space when creating the file. So the disk isn't really excluded. It won't make the /mnt/disk1/media folder by itself, but it will still list the content if it exists. It doesn't allow me to make new files/foldes in /mnt/disk1/media, but I can do anything with existing ones, and even with all other disks full I can change a small file into a big one, with the changes ending up in /mnt/disk1/media.
  7. RiffSphere
    Hi, When creating a share with only primary storage set to array, and excluding all disks, instead of creating a share with 0 bytes free, it will not create a share, and it doesn't give an error: https://imgur.com/fAg6AZy I can understand the share is not being created, since there is no disk to create the folder on, but an error message would be nice. A bigger issue is if the share is already created and disks get excluded. This is my share with all disks included: https://imgur.com/W37KaBG Editing the share and excluding all disks: https://imgur.com/sBAMGT7 And the share still shows free space (this matches the size of my disk1, containing the folder): https://imgur.com/zwNb3Ik Clicking the compute button will even tell me the size is 6B and disk 1 is out of designated disks: https://imgur.com/bE1G8r3 I created a "test" folder on disk2 as well: https://imgur.com/ce1gPgM Now the free space is showing the sum of the 2 disks. Compute does report correctly though: https://imgur.com/zHmmyDc Making a file file on an excluded disk, also still shows the file in the share: https://imgur.com/fdQzWxh Editing (even after removing disk2 from excluded disks) or deleting the file, will update this on disk1 https://imgur.com/95szcq0 Even if the file edit is relative big, it still works: https://imgur.com/9C30KGF I understand that https://docs.unraid.net/unraid-os/manual/shares/user-shares/#included-or-excluded-disks states "Never set both values, set only the one that is most convenient for you.", but if I don't select any specific disks as included, it defaults to "all", with no option to not set this. This makes the exclude function worthless, the only way to exclude a disk is to not have it in the included disks to begin with (something I don't want, cause I want all current and future disks available to a share, apart from 1 disk I want to exclude, and setting specific included disks will not add my future disks). I really think we need an "all except excluded" option for included. To make things more confusing, when trying to create a file on a share with all disk excluded, but reporting free space, I get the error of no space left, even when df is showing free space: https://imgur.com/vPb2fnX So in some way, the exclude is being done? But partially? So I'm really confused now: - Included disks have priority over excluded disks, but I have no good way to make use of excluded disks. - Free space on excluded counts towards the free space reported by the share. - Existing files on excluded disks are listed, can be opened, edited and deleted without issues. So far, while I don't like it, it still follows "all disks are included so the excluded disks does nothing". - Making a new file will tell me there is no space, though everything indicates to me there is space, and I can even edit existing files and make them a lot bigger.
  8. RiffSphere
    Hi, Not sure if this is unraid or community apps, but since it's now so closely integrated with a single button install, I'm going to post this here. Please move if needed. On a new server, I created an "appdatapool" pool: https://imgur.com/8eDRjBk Next, I made the appdata share an exclusive share with just that pool: https://imgur.com/ByPW7Yp My docker is configured to use /mnt/user/appdata as default appdata storage: https://imgur.com/oWTlntH Some containers, like IBRACORP's jellyseerr, seem to use the /mnt/user/appdata share correctly: https://imgur.com/6Vqbq34 However, it seems they just have it hardcoded in their template: https://imgur.com/undefined Other containers, like linuxserver's sonarr, will follow the symlink (according to the docs, exclusive shares are symlinks I believe?) https://imgur.com/Nenld06 Checking out their template, the Appdata path has no default, and should be filled from my docker config, I believe? https://imgur.com/gNo55wP Now, if I make the share not an exclusive share: https://imgur.com/50aXXEc And I try to install linuxserver's sonarr again, it does take my configured appdata share: https://imgur.com/jfR2Kao The docs (https://docs.unraid.net/unraid-os/manual/docker-management/#appdata) suggest that the appdata share should be used ("By convention the appdata share is used for this purpose, with each container using a container specific sub-folder in this location."). When I have an exclusive share, already bypassing the FUSE system and overhead, my appdata defaults to the pool, it seems to resolve the symlink. When not having an exclusive share, and one might actually want to put the appdata directly on the pool and not the share to bypass FUSE, the share is being used correctly. I know, it's just a few click to change this, but it's easy to forget an can cause issues down the line (for example, creating a new pool for appdata while keeping the old one in place, restoring a backup and changing the appdata share to use that, suddenly your appdata will be randomly split between 2 pools).
×
×
  • Create New...