Unable to chmod directory in GDrive shared folder

[traeki]

Host: Windows 10
Guest: Arch 64 (Manjaro-i3)

-- I have Google Backup & Sync running on the host machine to maintain my Google Drive files on a separate NTFS partition (D:\)
-- That partition is a VBox shared folder.
-- My username is a member of vboxsf.
-- As root (i.e. using 'sudo') I can make whatever changes to files I want to make, with one exception.
-- Without sudo prefix, my user can modify most files and directories in the mounted gdrive.
-- In the Host (i.e. Windows Explorer) I can freely edit and manipulate all Google Drive files and folders.

But, inside the guest, specifically in the case of folders that I have *shared in Google Drive*, which is to say they are shared with another Google User on the service side:

-- I do not have write permissions for the directories.
-- Though I can freely add files, subdirectories, etc with a sudo prefix, even sudo will not allow me to modify the permissions on the shared folder itself.

e.g.

> ls -hald oligo_libraries
dr-xr-xr-x 1 jsh jsh 0 Jun 25 17:38 oligo_libraries/
> sudo chmod u+w oligo_libraries
> ls -hald oligo_libraries
dr-xr-xr-x 1 jsh jsh 0 Jun 25 17:38 oligo_libraries/

I can work around the problem by just using sudo for any file operations that block on permissions errors. And I do have write permissions for all the files *within* the GDrive shared areas. It's just the directories themselves that I'm failing to alter.

What am I missing here?
Why is my VBox Arch guest unwilling to change the folder permissions for folders that GDrive has flagged as "shared"?
What is the cleanest fix?

Thanks!

[traeki]

In case it's relevant, here's the line of my /etc/fstab for the mount:

gd /home/jsh/gd vboxsf defaults,uid=1000,gid=1000,umask=0022

(folder is shared with the name 'gd' in VirtualBox settings)

[traeki]

More testing has clarified a couple of points for me:

1) I never can change permissions for the shared folder within my Guest.

2) That much is more or less expected.

3) The write permission on a folder is tied dynamically to whether it is marked as "shared" by Google Drive. Disabling sharing for a folder makes it writable in my Guest system as soon as the Google system syncs (i.e. as soon as my local file is no longer marked with the "shared folder" icon).

So there's some kind of disconnect in semantics between what Google Backup & Sync is doing to my files in Windows 10, and how that's being perceived by the vboxsf system on my Arch 64 guest.

The files aren't actually read-only in Windows, and indeed I can still manipulate them freely in windows (which I guess is implied by the fact that I can arbitrarily mess with things via 'sudo' in the Guest, since VirtualBox shouldn't have any more permissions than the user running it).

So I'm back to trying to discern what it is about these files that makes vboxsf turn off the 'write' flag...

Hopefully y'all have some ideas? :-/

[socratis]

Hopefully y'all have some ideas?

VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.

I would use a a true network share (SaMBa).

[traeki]

Okay, I'll look into that, thanks.

[traeki]

Okay, so that totally did the trick, thanks Socratis.

That said, WOW, there is a LOT of noise in the signal around Samba sharing...

So, for any who come here seeking wisdom in my wake, here's what I had to do to get this working (obviously please offer critiques if it can/should be improved)

1) Created a local user on the Windows Host called vbox
-- This is kind of a pain, you have to keep telling Windows "no, really, I don't want to add a Microsoft User, goddamnit" over and over, but you can get there eventually.
2) Created /home/<guestuser>/.smbcredentials on Guest with "username=vbox\npassword=<password>"
3) Shared the relevant folder with vbox in File Explorer as 'netgd', giving vbox Full Access permissions
4) ran 'ip route' on guest to get the default gateway.
5) Added an fstab line:
\\<gateway>\netgd /home/<guestuser>/vbgd cifscredentials=/home/<guestuser>/.smbcredentials,defaults,uid=1000,gid=1000

(Note: "vbgd" was my arbitrary path, you can make this whatever. Ditto "vbox")
(Note: cifs doesn't understand umask parameter, so don't specify that like you might have for vboxsf)

then either run
sudo mount -a

or reboot Guest.

And at that point I think I had it working.

Directories were still read-only, which continues to be a source of consternation for me, but I was now able to actually chmod u+w and fix the problem. Hopefully that'll stick... Grr.

[traeki]

Hmm. Actually, that does work as described when I call

sudo mount -a

But not when I reboot. I have to call sudo mount -a again before I can access the drive.

Any idea why that would be or where I can find mount-cifs errors from boot?

[traeki]

Okay, figured this out, basically the mount wasn't showing up in time for the mounting routines to be happy. I had to tell them to "chill....waaaaaaaiiiit fooor iiiit".

Did that by adding the following parameters to the fstab entry:

x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1

Not sure if all of those were necessary, but they do appear to have been *sufficient*.

[traeki]

Ugh. One residual issue:

When I edit files in the cifs mount using vim, I get warnings starting the *second* time I attempt to write the file.

WARNING: The file has been changed since reading it!!!

I'm guessing that's because the write operation is updating the timestamp before Samba is finished mucking about with the file. The contents and permissions don't seem to have changed, though.

::grimace::

Any ideas?