Replacing a file on the drive, windows wants admin credentials...?

[Ben Spink]

Drive is working well providing access to a HTTPS backend server.  From MacOS with OSXFuse, replacing a file is fine.  (Copying a file to a folder where it already exists and needs to be erased and replaced).  But with WinFSP, some OS scenarios, it prompts indicating "Destination Folder Access Denied"...but I don't know what made it determine this.  It's not true.  You can delete the file, and then copy with no file being present and there is no error.  So full management is working through the drive, its just the overwrite that windows prompts indicating you must continue with administrative privileges for some reason.

Is there some attribute that is not set on the directory listing I returned, or some attribute that is defaulted which is causing this?  Personally I can't replicate this on my Win10 environment...but I think my account is already an admin there.

Wondering if you know what is triggering this?

I counted 166 getattr requests when the attempted drag and drop of an existing file was done...and somewhere in that, windows decided the user had to do the admin continue button.....?

[Bill Zissimopoulos]

There are two primary reasons for "Access Denied" in Windows:

 

• Permission problems where the granted permissions are not enough for the requested operation (as in UNIX).
• Attempts to perform an operation that is not allowed because the file is in use (specific to Windows).

 

It is not always obvious what the underlying cause is. I recommend using the `fsptool` utility that is included with WinFsp to view Windows permissions (use `fsptool perm .\FILENAME` for this) in SDDL format. Another tool that I often use for this purpose is the Windows built-in `cacls /S`. These tools reports permissions in SDDL format (it is a good idea for Windows file system authors to become familiar with the Windows security model and SDDL):

       https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language

 

If the problem is that another application is also using the file, the SysInternals Process Explorer or the command line utility Handle can help with identifying the application.

 

Bill

--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winfsp+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/14525785-bbae-49c0-82d8-1556523dc2cbn%40googlegroups.com.

[Ben Spink]

ok...but...

You can delete the file on the drive before attempting to replace, and that is fine.  (I don't mean deleting behind the scenes, I mean in the virtual drive, deleting it.)  No prompts, no warnings, everything is fine.

The file is not in use...it can be deleted.

This is only an issue with the virtual drive...the object behind the scenes is completely fine and no restrictions at all exist on it.

Clicking Continue, and it has no issue over-writing the file.

Something about the getattr call made it think overwriting was not going to be OK without administrative permissions...is it the uid/gid?

Example code snippet of the stat object which was configured in the getattr call.

stat.st_mode.set((p.getProperty("type", "FILE").equalsIgnoreCase("FILE") ? FileStat.S_IFREG : FileStat.S_IFDIR) | 0777);
stat.st_uid.set(getContext().uid.get());
stat.st_gid.set(getContext().gid.get());
stat.st_size.set(Long.parseLong(p.getProperty("size", "0")));
stat.st_mtim.tv_nsec.set((Long.parseLong(p.getProperty("modified", System.currentTimeMillis() + ""))));
stat.st_mtim.tv_sec.set((Long.parseLong(p.getProperty("modified", System.currentTimeMillis() + "")) / 1000L));

[Bill Zissimopoulos]

The FUSE layer of WinFsp includes an automatic translation from UNIX UID/GID's to Windows SID's and UNIX rwx permissions to Windows ACL's. For this to work correctly your file system must supply reasonable values for UID/GID and mode in the getattr call.

 

Alternatively you can set those values from the FUSE command line using options like -ouid=UID,gid=GID,umask=UMASK. WinFsp also supports the special value of -1 for UID and GID, which means to use the UID/GID of the user who launches the file system. For example: `-o uid=-1`, will make the user who launches the file system the owner of all files.

 

The utilities I mentioned earlier would help you identify problems such as these.

To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/ee9b740b-f9fe-45b3-82f6-afa02748f463n%40googlegroups.com.