• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About vexingv

  • Rank
  1. Thanks for pointing that out. i have not tried it, but after looking at that post, it seems that with Jun's loader, 16 drive bays are the default on 918+, thus i guess i should be good to go since i will be using fewer than that.
  2. ^^^ bump I'm curious to find out as well. I just switched from 3617 to 918+ as it seems to include newer features. While I currently only have 4 drives installed, I still have 2 spare SATA ports on my motherboard. I know the 918+ has only 4 drives; if i just plug in two additional drives, will they automatically be recognized? Do I have to edit/modify any files so that it can use/recognize the two additional drives/SATA ports?
  3. I've been running an xpenology server since 2015 with DSM 5.1 until last year when Plex required a transition to DSM 6 with x64 packages. I then upgraded to DSM 6.1 with Jun's 1.02 loader and had been fine with that. Wanting to get more performance, I decided to upgrade my CPU from an i3-4130T to a Xeon E3 1285L V4, the best/latest CPU supported by my ASRock E3C226D2I motherboard, which has Intel Quick Sync support. As this was a significant change, I decided to change to upgrade to DSM 6.2.2 and take advantage of HW transcoding support in Plex too. Installation and migration went
  4. has this problem been fixed/addressed in DSM 6?
  5. i'm bumping this thread as i now see that many are now using DSM 6. has this issue with ACL/permissions on encrypted shares been fixed in DSM 6? thanks.
  6. Doman, sorry of the very late response. The only solution i found was to downgrade to DSM 5.1. I'm hoping this will be fixed when DSM 6 is released, whenever that may be.
  7. i wound up downgrading to 5.1.5055 to create some shares and change my ACL permissions. then i upgraded to again 5.2.5644. however, even with the ACL permissions corrected, i still had problems writing to the encrypted shared folders (getting errors that i did not have permission) on DSM 5.2. ultimately i had to downgrade to 5.1.5055 again and it looks like i'm sticking with that release until the issue has been corrected. i'm not sure what the new features are between DSM 5.1 and 5.2, but i'm also concerned of any security updates and other bug fixes that may have been corrected since DSM 5.1
  8. That bug is quite annoying as there are some new features in 5.2. I'm surprised it has not been addressed in over 6 months. While less than ideal, have you downgraded to change/edit/create permissions, then subsequently updated to the latest 5.2 version?
  9. i tried on 5.2.5592 and 5.2.5664 and i have this problem as well in that i cannot edit ACL/permissions for existing encrypted folders, nor can I create any new encrypted shared folders either. is this a confirmed bug that is only correctable via downgrade to DSM 5.1? or have there been any solutions/fixes in the interim?
  10. When i first setup my xpenolgoy system earlier in the year (can't remember which version i started with but likely 5.1), i created a couple of encrypted share folders and things worked well. recently, i wanted to create another encrypted folder and wanted to add permissions to an encrypted shared folder for a new user. however, i cannot make changes any changes to the ACL/permissions of the existing encrypted shares nor can i create new encrypted shares. the error message i received reads: since creating those first encrypted shares, i had upgraded to DSM 5.2 (5.2.5565, 5.2.5592 and now