upload goes to personal folder instead of shared folder

[galettof]

Describe the bug
I set up a shared folder in business_shared_folders, and synced with --sync-shared-folders. The shared folder was downloaded to my local OneDrive folder. After adding some files locally and syncing again, the entire shared folder was recreated in my cloud OneDrive folder with the new files, but the new files were not added to the actual shared folder online.

Application and Operating System Details:

• Debian 10, Linux nuc 4.19.0-16-amd64 Fix config folder. #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
• use a Gui
• OneDrive Account Type business
• built from source
• DMD version unknown because I uninstalled, it's whatever version was new for Debian 10 approximately a month ago
• using onedrive v2.4.11-7-gb0771f7
• Output of onedrive --display-config:

Config path                            = /home/fez/.config/onedrive
Config file found in config path       = false
Config option 'check_nosync'           = false
Config option 'sync_dir'               = /home/fez/OneDrive
Config option 'skip_dir'               = 
Config option 'skip_file'              = ~*|.~*|*.tmp
Config option 'skip_dotfiles'          = false
Config option 'skip_symlinks'          = false
Config option 'monitor_interval'       = 300
Config option 'min_notify_changes'     = 5
Config option 'log_dir'                = /var/log/onedrive/
Config option 'classify_as_big_delete' = 1000
Config option 'upload_only'            = false
Config option 'no_remote_delete'       = false
Config option 'remove_source_files'    = false
Config option 'sync_root_files'        = false
Selective sync 'sync_list' configured  = false
Business Shared Folders configured     = true
business_shared_folders contents:
MTH 220 collaboration docs

• Output of curl --version curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
  Release-Date: 2019-02-06
  Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
  Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

• 'sync_dir' is local, on ext4 partition

• OneDrive folder is accessed through the Linux pc where I am have the problem, and through a Windows pc

Emailed logs to support@mynas.com.au

To Reproduce
see bug description

Additional context
issue looks like #1111

[abraunegg]

@galettof
This is potentially down to user error.

When you setup OneDrive Business Shared Folders, you need to always sync with --sync-shared-folders or set sync_business_shared_folders = "true" in your configuration file.

Can you please confirm how you were syncing - what was the exact command you were using when this issue occurred.

[galettof]

I synced with --sync-shared-folders. It is however possible that onedrive ran as a background service before I ran it manually. Since I never needed shared folders before, I don't have sync_business_shared_folders = "true" in my configuration. If that was the case, then the files would have been uploaded to my OneDrive folder instead of the shared folder, which would case them to always upload to my folder in the future, right? Assuming this is the issue and the shared folders option is set to true in the configuration file, would it be enough to delete the copy of the shared folder that was created in my OneDrive folder and wait for the next sync?

[abraunegg]

@galettof

It is however possible that onedrive ran as a background service before I ran it manually

This is possible, but only in the following scenario(s):

• You installed from the Debian package, before compiling from source, thus hit by this issue: Ubuntu PPA | Ubuntu | Debian Packages: onedrive --monitor runs automatically on startup after install #1274
  • It appears that the Debian package is the root / source of this issue
• You installed from source to update the client, but did not disable the 'faulty' systemd entry above created
• You manually activated systemd services and whilst they were active syncing using the default configuration, you performed a manual sync of your shared folders

Assuming this is the issue and the shared folders option is set to true in the configuration file, would it be enough to delete the copy of the shared folder that was created in my OneDrive folder and wait for the next sync?

Always test with --dry-run - this is why this option exists.

[galettof]

I compiled from source and activated systemd services. I got the shared folder to download locally by syncing manually with --sync-shared-folders. The automated sync up to the cloud must have occurred before I got a chance to do anything else, causing the local copy of the shared folder to be uploaded to my personal OneDrive instead of back to the shared folder. I remember using --dry-run after putting new files in the local copy of the shared folder, but by that point the automatic sync had already uploaded to my personal OneDrive.

I cleared my whole configuration and local OneDrive folder, then set up up shared folders before syncing anything. Finally synced everything manually once and reactivated systemd. It seems to be working fine now. Thanks.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.