Page 1 of 1

[.02] Access Denied on file renaming/moving on network drive

Posted: Sun Oct 21, 2012 6:28 pm
by Leroy
I have a shared folder with appropriate access permissions for example "10.0.0.0.1\tmp" on Computer C1. I connect it with computer C2 (running sandboxie 3.74) als drive z: and set drive z: to "Full Access". I can write, change and delete files but I can not rename or move files within that folder (z:\ and below) or to other folders of the same type. It always gives "Access Denied". The same rename/move operations do work outside the sandbox, like in a non-sandboxed explorer or Total Commander. This problem apparently also only occurs with windows 7 64bit, I had no problem with Windows XP. It also works if the folder is not set to full or direct access, so that move/renaming is only performed in the sandbox folder. But that's of no help for me.

I tried Sandboxie 64 from 3.52. to 3.74 and also started the sandboxed applications in administrator mode.

Posted: Mon Oct 22, 2012 5:12 am
by tzuk
Are you sure you see an "Access Denied" error message? I get a "Folder In Use" error message. And I can't rename the new folder I created. Thanks for the problem report, I'll make a note to look into it.

Posted: Mon Oct 22, 2012 6:39 pm
by Leroy
tzuk wrote:Are you sure you see an "Access Denied" error message?
Well, I can't tell the exact error message because my Windows is German. Furthermore Explorer says "Folder access denied" while Total Commanders asks me to remove the "write protection". So it may very well be that the file is somehow marked as beeing in use.

Posted: Fri Oct 26, 2012 7:48 am
by Leroy
It would be really nice to fix this with the next update as I just noticed it also effects simple downloads to network folders. I always run Firefox in a Sandbox and downloads usually go to a folder on a network drive. But Firefox downloads files with ".part" extension and renames them finally when the download is complete be removing this additional extension - which doesn't work because of this bug.

Posted: Fri Oct 26, 2012 10:02 am
by tzuk
I will look into it. For now, you might be able to work around this problem by downloading files to your desktop and then use the Immediate Recovery window to move them out to the network once the download is complete.

Posted: Fri Nov 30, 2012 11:55 pm
by dragonetti
I think I may have the similair problem (but I am really not sure).
  • Windows 7 64 bit english
  • UAC turned off
  • Network share = T:\ and trying to sync 2 folders on T:\ => folder [A] and
  • Access to the network share is done with windows 7 credentials
  • The program that is running in sandboxie is "GoodSync"
  • Sandbox Settings >> Resource Access >> File Access >> Full Access >> "All Programs" , Access to "C" , "D" , "T"
    C and D are my local drives and T is the Network share
  • Sandbox Settings >> Restrictions >> Drop Rights >> "Drop rights from Administrators and...." => UN-CHECKED
    This was automatically detected by sandboxie after GoodSync was installed, I got an pop-up requesting to press a button that un-checked the above mentioned option ("Drop rights from Administrators and....")
  • All other options within the 'Sandbox Settings' are left default


GoodSync works perfectly with the network shares and locally when installed outside sandboxie

I encountered this problem when I was starting with Sandboxie and was asking questions in this topic:
http://www.sandboxie.com/phpbb/viewtopi ... 5577#85577

A search lead me to this topic.

My apologies for cross posting, I normally don't do that.

Posted: Mon Feb 25, 2013 2:31 pm
by tzuk
Regarding the probem where setting a network share/drive as an open path (or direct access or full access),
then not being able to issue rename or move commands against that path:

Version 4.01.02 should fix this problem.

Posted: Thu Mar 28, 2013 3:56 pm
by bfu
tzuk wrote:Regarding the probem where setting a network share/drive as an open path (or direct access or full access),
then not being able to issue rename or move commands against that path:

Version 4.01.02 should fix this problem.
Seems it surfaced again in 4.01.04 (x32). I'm getting the exact same behavior as described earlier in the thread.