locked
Permissions Reset? RRS feed

  • Question

  • Very strange and I am pretty sure this is not by design.

    If I RDP into my box & add a permission to the Photos share for say: test with read/write access the permission get sreset a few days later.

    I know this sounds trange but it's true I can set the permission and check back a few hour later and it is still there but at some point it resets.

    Still can't figure out the exact point but i am wondering why this keeps doing this.

    Any suggestions?




    Saturday, March 15, 2008 1:51 AM

Answers

  •  JonTheTech wrote:
    Yes & No.

    Originally to set the permissions YES.

    But then I went in via RDP to edit them because I just prefer that over the console.

    Maybe I "must" use the console?

     

    You should.  I have seen other people have the same problem you're having by not using the Console.  What has worked for me is to alter the permissions on a folder inside one of the WHS shares.

     

     JonTheTech wrote:
    That seems rather limiting being on NTFS mount and only have 4 permissions vs ntfs permissions. (23??)

     

    Actually, it's only 3 (no access, read access, full access).  I believe one of the functions of the storage manager is to make sure permissions match what WHS allows (which is why every time I run the storage server diagnostic, I get a Tombstone ACL Doesn't Match QSM for each file in the folder where I set the permissions manually).

     

    You need to keep in mind the target audience of the server:  people who know nothing about permissions in the first place.

    Saturday, March 15, 2008 2:24 AM
    Moderator

All replies

  •  JonTheTech wrote:
    Very strange and I am pretty sure this is not by design.

    If I RDP into my box & add a permission to the Photos share for say: test with read/write access the permission get sreset a few days later.

    I know this sounds trange but it's true I can set the permission and check back a few hour later and it is still there but at some point it resets.

    Still can't figure out the exact point but i am wondering why this keeps doing this.

    Any suggestions?

     

    Are you using the Console to set your permissions?

    Saturday, March 15, 2008 2:03 AM
    Moderator
  • Yes & No.

    Originally to set the permissions YES.

    But then I went in via RDP to edit them because I just prefer that over the console.

    Maybe I "must" use the console?

    That seems rather limiting being on NTFS mount and only have 4 permissions vs ntfs permissions. (23??)
    Saturday, March 15, 2008 2:13 AM
  •  JonTheTech wrote:
    Yes & No.

    Originally to set the permissions YES.

    But then I went in via RDP to edit them because I just prefer that over the console.

    Maybe I "must" use the console?

     

    You should.  I have seen other people have the same problem you're having by not using the Console.  What has worked for me is to alter the permissions on a folder inside one of the WHS shares.

     

     JonTheTech wrote:
    That seems rather limiting being on NTFS mount and only have 4 permissions vs ntfs permissions. (23??)

     

    Actually, it's only 3 (no access, read access, full access).  I believe one of the functions of the storage manager is to make sure permissions match what WHS allows (which is why every time I run the storage server diagnostic, I get a Tombstone ACL Doesn't Match QSM for each file in the folder where I set the permissions manually).

     

    You need to keep in mind the target audience of the server:  people who know nothing about permissions in the first place.

    Saturday, March 15, 2008 2:24 AM
    Moderator
  • Backdooring the Windows Home Server Console around user permissions can get you in a real mess.  I would never recommend it.   

    Saturday, March 15, 2008 2:46 AM
  • Ok.

    I know I am using my system outside of support from go.

    Running php+mysl on it hehe. I was just curious that's all.

    I will make sure I keep the permissions managed via the console and go from there.

    Thanks for the update.
    Saturday, March 15, 2008 11:27 AM