[Temp Solved] Directories sync, but files do not

Bugs and issues Linux
#1

My best guess is that the issue is related to file permissions. Currently insync-headless is running under user account “server” and “server” happens to be in group “client” with user “client”. The directory space assigned to insync is /home/“server” and the user "client"s files are being sync’d under /home/server/client@domain.com. All the files in directory client@domain.com belong to the namesake group (ie, chgrp -R client /home/server/client@domain.com) and all new files being written to that directory automatically belong to the same group via chmod g+rwxs. Because client@domain.com is actually a samba share for the very same user, all new files being created by the user actually belong to client:client, and not server:client. However, this shouldn’t be an issue because all new files create as drwxrwx–x and “server” belongs to the “client” group.

To throw a wrench into my theory though, I created a directory named test and a file named test.txt that was explicitly created by “server” under the client’s samba share. Even though user “server” is running insync and those files are owned by “server” it still only created the directory and didn’t move any files. I’m at a loss right now as to why I can’t sync files to GDrive. The only way to sync new files is for me to delete my account and readd it.

#2

I am having the same issue. It writes the directories but will not write the files. I have had that in the past and changed permissions to allow “others” read/write access and this fixed the issue before, but it is not with this new version of Insync. This is a critical problem.

#3

Weird, I’ll add permissions for others and see what happens, but if that works that’s not a solution given the privacy and security risk. It would be insane to think that the user running insync would need other permissions when they have either group or owner permissions. I’ll report back in a second.

#4

Yep, o+rwx doesn’t change anything on my end either. This essentially makes Insync a non-starter for any multi-user environment. Although, even if it did work with o+rwx that’d still be unusable 90% of the time anyway. Generally users don’t like their files world readable.

I am interested to hear from Insync as to what this behavior may be caused by, and if there is any stop-gap measure that can be made in the interim.

#5

The temporary solution seems to be to force SAMBA to inherit file permissions and then give o+r to everything in the directory structure you are syncing. In samba, this can be accomplished by using inherit permissions = yes option in the smb.conf file under whatever users would be configured that way.

However, it still seems odd to me that you can’t sync with group permissions considering the group is +rwx. Previously the mask being used was rwxrwx–x, but it seems to be syncing fine with rw-rw-r–. There shouldn’t be any need to give world readable permissions to a file though.

#6

Also, it seems important to note that Insync appears to ignore files that are not inherently o+r even if they become o+r later. This would explain why David was not able to chmod his files to sync after they were created. I believe that the behavior of Insync (whether intentional or not) is to initially check permissions and then make all future decisions based on the initial ones set.

#7

Yeah, still not syncing, permission change or not. Tech support has not been much help in the past but I may try them again. Usually they take the logs and then write back saying that its syncing, when it is not. Right now, the program “counts down” files to 0 then counts them back up to 161,000+ (no kidding) then back down to 0, then back up, etc. Been doing that for over 7 days. Exciting to watch but it would be nice if it actually synced

#8

The problem seems to be that once Insync sees a file that is not o+r, no subsequent change will allow it to sync. Therefore you cannot chmod -R g+rwxs and then chmod -R o+r and expect everything to start syncing after the fact. My solution was to literally setup a new directory structure where all new directories and files were copied/created as rw-rw-r-- and then paste all the data back into that structure, and then it seemed to sync after that. I would test it with manage_selective_sync, make a test dir and paste stuff into it that’s already o+r.

#9

Hi guys, I will tag our engineer @lpugoy and @dipesh so they can look into this.

#10

@Phillip: I’d like to clarify a few things about your setup:

  • What user and group is the Insync process running as: ps -eo uname,group,args | grep insync?
  • What is the umask of the Insync process? This should be the same umask as the user running it.
  • What are the permissions on /home/server/client@domain.com: ls -ld /home/server/client@domain.com?
  • What are the permissions of new files and folders under /home/server/client@domain.com that weren’t created by Insync, i.e., that were created by other users of the Samba share?

Lastly please send your logs to support@insynchq.com for investigation: How to find the log files. @David_Moraine please send your logs as well. Thanks.