Solved One of Folders from Drive Team folder disappeared and stop sync

Currently reading
Solved One of Folders from Drive Team folder disappeared and stop sync

2,486
840
NAS
Synology, TrueNAS
Operating system
  1. Linux
  2. Windows
Background:
DSM last ver: 6.2.3-25426-2
Drive Server last ver: 2.0.2-11078
Team folder contains 8 folders for the Drive services
Multi OS Drive clients in operation, also web Drive client
Drive desktop clients (Win/Ubuntu) in last ver

Behavior:
- 7 folders from 8 are running in normal operation (seen in Team folders structure in any devices/OSs/browsers also synced as expected)
- the last we can call "DOC" disappeared from all Drive client's APPs (Team folders structure), also from web Drive client (browsers) and can't be available for client side. This Shared folder isn't encrypted.
- the "DOC" folder has been used last time 2 weeks ago with expected sync, no troubles
- the "DOC" folder is available by SMB/CIFS/NFS and no read/write troubles discovered
- now I have just one hint, based on Win Drive client console = Account does not have write privileges (see in the picture below)
to be sure this Drive client share just 5 from 8 folders in Team Folder structure (reason why you can see in the attached picture 5 synced folders)

1596455146985.png


What has been checked:
1. Drive Server Admin Console:

- Team folder .... the "DOC" folder is in ENABLED status
- Settings .... no special settings in Users Sync Profiles defined for this folder
- Log .... I can see filtered logs for the "DOC" folder, also written by SMB events in Today (also test files created in File station directly)
Works as expected.

2. File Station:
- write (new file, folder) by same user is performed w/o issue. OK, done.
- Shared folder "DOC" Properties/Permissions:
a) user (used for the Drive client;s APPs) is visible and ALLOW for Read/Write, checked details = OK, done
b) doubled by Advanced options/Permission inspector = OK, done
c) Applied for sub-folder structure = to be sure, OK, done
Then no permission issue was discovered.

3. Browser Drive client (FF, Chrome, Edge, Safari):
- folder "DOC" isn't visible in the Team folder structure
- User icon, then Log .... I can use filter of the Logs for the "DOC" folder = then I can see last

4. Win Drive client:
- as was described above is running with "write privileges" error
- when I try to CREATE new sync task, the folder "DOC" isn't visible in Team folder structure
then it must be error at Drive Server side
ok let's check it now in different way

5. Disable and re-enable the "DOC" folder in Drive server Admin Console:
- browser client - doesn't see the folder in Team folder structure
- Win based client = same situation .... same for Ubuntu client
- iOS client = same situation
then this step isn't helpful for this issue

6. Another Existing Shared Folder enabled in Drive Admin console
- folder seen in Team folder structure in all clients (desktop, mobile, browsers)
- synced as expected
seems to be Drive server works well

7. New Shared folder created, copy of entire "DOC" folder to the New Shared folder
- enabled in Drive Admin console
- folder seen in Team folder structure in all clients (desktop, mobile, browsers)
- synced as expected

Verdict:
- seems to be this is not clear issue of the Drive server for the particular "DOC" folder.
- seems to be there is fights about the privileges, no reason found
- ticket in Syno Support issued

Any thoughts?
 
Fortunately
I got answer for my ticket really fast from Syno support

Unfortunately
it was from person with low level knowledge of Syno environment, even basic principle of file storage operation
look for that:
--------------
Please delete and recreate your drive client to the system partition to the default recommended directory.

Some other folders and other partitions dont have the right permissions or are unfortunately not supported.

Please create a new shared folder via filestation and activate that as a teamfolder. Make sure, that no other services use that directory, because that could produce trouble on sync. Please do not use also a same directory or subdirectory from another sync, because that is not supported.


(I deleted links for Syno Drive knowledge base reading, recommended in end of this official Syno support answer)
--------------------
this is another example of existence for Pareto principle.
 
what works - is New Shared folder create (see above in my description, step No. 7)

It's opening a consideration:
- user authentication to the NAS is OK for the user (Drive client)
- something must be wrong in the Shared folder permission (authorization). No idea what, because Permission Inspector is out of an evidence.
- and it was discovered from last DSM update, never before.

What is really disturbing for me - when it will happen in different Shared folder and I will lose versioning .... hm it will be a bad day for me.
 
follow all my analyse outcomes:
- seems to be this unwanted "feature" is related with time of update to new DSM version: 6.2.3-25426-2
- I see it as possible unexpected authorization bug discovered only in the handling process within System granted resources for a particular UserID and Drive task
 
it took just 10 days and 8 posts for understanding of gentleman from Syno support, that his knowledge isn't sufficient and he decided today to move ticket to deeper tech support level.

It's really funny, when Syno asks from you DSM debug log + Drive debug log. Because it contains really sensitive information about everything in your NAS, include user names, FDQN, IP addresses, folder structures, User IDs, .... no one know where it will be stored and who can see all the files.

There was really nice recommendation from the gentleman - "open file in text editor and use replace feature for the sensitive data"
This guy never did such debug log extract, because there is list of >2500 files (and additional 3000 for Drive).

I prepared for him extract from Drive client logs, Drive SQLite extracts, ... no errors at Drive side, just few [WARNING] for file with restricted characters "~" in filenames: created by MS Office Apps (Excel/Doc) for recovery files.
As we know Drive can't sync these files, but this isn't a reason of write error = my issue.

What is more important I tried another test to make sure that there was a problem with permission handling:
1. Connected to the Drive client as user with Administrator permission
2. this user OFC has full W/R privileges for the Shared folder
3. I can't see (mentioned user) the Shared folder in Team folder structure from Drive client side (desktop/browser client)
4. all rest of the Shared folders in Team folder structure are available and sync work well.
5. clean copy of the all data to new Shared folder makes the data available in Drive Team folders.
 
It's really funny, when Syno asks from you DSM debug log + Drive debug log. Because it contains really sensitive information about everything in your NAS, include user names, FDQN, IP addresses, folder structures, User IDs, .... no one know where it will be stored and who can see all the files.
Wow, that's not good...
 
So finally from almost 6 000 files initially requested from Syno support, from today they needs just two of them.
What a change!
20-minutes spent with secure/replace all sensitive data there

And one joke from Syno support for a sharing with you:
- could you pls. disable file filters from Drive client in the specific Team folder?

OFC - but the folder disappeared from Team folder structure = I can't see it in Drive client side = I can't enable/disable file filters. As was described in my initial ticket.
This summer is really hot in the support center. 🥵
Sometimes I feel like Yossarian in Catch-22.
 
Summary from today's Synology team Remote support investigation:
7 minutes read, but useful for people who get new experiences
-------
Summary of the problem:
- Drive clients (browsers, Smart apps, Desktops) unexpectedly lost access to one of Shared folder within Team folders (operated >5y w/o changes)
- access was lost also for user from Administrators group (tested)
- The Shared folder is Enabled in Drive Server Admin Console
- The Shared folder (entiresub structure) is available from File Station and SMB mounted sessions (Win, Ubuntu)
more you can find above

Remote assistance from Syno engineers by:
TeamViewer session (two of my computers), then SSH to NAS by MobaXterm (SSH+SCP) + browser sessions to DSM and Drive client. Chat only by TeamViewer. They rejected video channel, proposed by me for better communication.

1. during first 40 minutes of investigation wasn't discovered problem in logs (DSM, Drive)
- Drive SQLite DB check & investigation
- Drive-debug.py investigation
Code:
/tmp
/tmp# chmod +x drive-debug.py
/tmp# ./drive-debug.py database --check
integrity check needs tobe in "OK" stage
- Drive server logs investigation
- Team folders "enabled" confirmation for the problematic Shared folder
- Drive client.log investigation
Code:
/volume1/@synologydrive# client.log
this log is better to debug from DSM to your PC, then open it as TXT import to e.g. MS Excel and use more filters for precise navigation. File is created periodically (old versions are preserved), then you need find date creation of your interest.
Code:
/volume1/@synologydrive# sqlite3 /volume1/\@synologydrive/\@sync/user-db.sqlite "select * from user_table"
no ERRORs or WARNINGs related to this issue

2. File Station investigation

- connected as user from Administrators group
- the Shared folder works as expected (file/folder creation, delete, copy, paste)
- the Shared folder Permission inspection (File station GUI) checked
no problems found

3. SMB share tests (mounted Shared folder in WIN/Ubuntu)

- connected as user from Administrators group
- all the sub-parts of the Shared folder was accessible
- the Shared folder works as expected (file/folder creation, delete, copy, paste)
no problems found

4. Drive clients check

- browser can't show the Shared folder within Team folder structure
- same for all desktop/smart Drive clients
the problem persists - they don't have clue about reason(s)

so I reminded them that it must be an Authentication/Permission problem
then I showed them basic command
Code:
ls -l
in the affected Volume
and there was the problem confirmed (as was from beginning of my ticket):
the Shared folder permission (and all data sub-structure) lost permission
there was just --------- (what isn't good for user from Administrator group)
what was totally different from GUI Permission inspector (all was fine there)
then I rewrite again the
Code:
chmod
permission and - PROBLEM was SOLVED

The main questions set remained unanswered:

Why after the update of DSM when this problem was discovered, only for one specific Shared folder - lost ALL privileges also for Administrators group? Wiped privileges and hidden in Drive Team folders. But the permissions remain for File station and SMB? Where the permissions remain recorded?

Conclusion:
1. when you write a description to Synology Ticket, be precise and try to write all things + screen shares.
No one will read it carefully, but it will be helpful :rolleyes: for some who needs know more

2. you will spend 2 weeks with someone from first line support, then your ticket will be moved to deeper level.
I'm really unhappy with this part of support flow.

3. the engineer from next level Syno tech support was skilled in SSH, of course. No doubt.
But we could save time if she was read my entire ticket carefully, or she was listen (read) what was offered (check SSH folder permission) from me during the today's remote session.

4. after additional consultation with senior engineers from Syno (from my demonstration with "ls -l"):
she agreed that Syno team had no idea how the loss of permissions could have occurred. And since DSM doesn't log permissions changes, they decided to send it to DSM7 team as a suggestion for improvement in next gen DSM.

5. they confirmed - it's strange that wiped permission was valid only for Drive operation, because it was miraculously functional (does somewhere exist) for:
- File Station usage from DSM browser session
- File Station from Smart App (remote access)
- all connected (mounted) sessions by SMB (WIN/Ubuntu computers)

Last, I'm glad that this problem was occurred, because they can start thinking about how to deal with a prevention in DSM7. Must say, that communication with deeper level support was really better than with the guy from first level.

Lessons learned:
You have to resist the first Syno support requirement that you have to allow remote access to your NAS (Remote Support center services in DSM). This is uncontrolled access to your data store with administration permissions. Dangerous.

You have to resist also for another request to generate complex DSM debug logs (or another packages logs) and ask them for particular file/files from the debug log. You can save the debug log to your computer, then rename the file to .ZIP and unzip the content. Easy. Then you have to check the requested file(s) for a "sensitive" info. Be careful who will read what.
In next round they will ask from you just few files. Because they really don't need all 6000 files for the investigation.

When you resist till this stage, they will offer for you TeamViewer session(s). What is more secure than both mentioned above. Then you can see all their steps and confirm downloads, changes, ... Also you can chat with them during the investigation.

Hope it will help someone to future.
 
I pass the 'long post' crown to you now!

It would seem that some packages operate on the ACL level and not with Unix permissions when determining if a user haas access. Then that these packages are running at full root privilege and not checking Unix at all, even for their own processes. Also that Drive Admin processes do run with Unix privilege checking, in addition to ACLs.
 
yeap, it was one of my "chat" question, but they stuck on it :cool:
there is still valid question - why was the privileges overwritten for the entire Shared folder and by what process?
 
In DSM 5.0 or later version, the access permissions of shared folders are based on Windows ACL by default.
Then you have grayed out this option in Control panel/Action/Convert to Windows ACL.

But this Shared folder is older than 5.5y (one of the oldest Shared folder in the NAS). Then there isn't set ACL by default and option in Action isn't grayed out logically.
Maybe a reason, why this fault has bee discovered by me and not by rest of users.
All other Shared folders used in Team folders are ACL defined.
 
Others have mentioned access issues and that package specific user accounts are owners at Unix level of the shared folders they create: I forget which it was ... /photo?

Anyway, my shared folders were created with DSM5 packages and aren't owned by package specific accounts. But maybe there's a strategy to limit root privilege use and this is happening to new NAS installations but there's some gap opening up for older deployments and not being fully accommodated. Surely must be some edge cases where privileges aren't as they expect. This can also happen when people change in the tech team and documentation is either lacking or too hard to follow: the new people's time 0 could probably be DSM 6 and they aren't aware of accounting for old legacy setups.

But that doesn't answer why the Unix access was reset to ---------.
 
Syno team had no idea how the loss of permissions could have occurred. And since DSM doesn't log permissions changes, they decided to send it to DSM7 team as a suggestion for improvement in next gen DSM.
From this ?? you marked the thread "solved"... if so, I'm not seeing the solution. Seems like "hopeless" is the more accurate status update.
 
@Telos - yes
but we have limited icons for thread statuses dependent from Syno support actions :cool: and I have to agree, when they haven’t logs, they can’t investigate primary reasons = what doesn’t apologize the issue existence.
As was written, I’ll be glad when this issue will improve next updates or new version.

smart people can find some hints derived from my experiences. And this is also way, how to help others (to future) in this forum.
One of them is the privacy protection requirements from customer’s side.
 
So final stage from Syno deep level support:

Dear Customer,

We have logged the issue and the developer will try to make the drive to follow all permissions of the file station.

Currently, it doesn't take all permissions as the file station.

So that's why you're able to access it via other protocol but not via the drive web/client.

Then due to there is no log related with the permission rules, we're not able to find out what process has make the permission disappeared.

We're deeply sorry for the inconvenience had cause.

Confirmed as was based on @fredbert suggestion:
- there is different permission source UNIX/ACL for Drive and for rest of mentioned packages/services (File station, SMB)
- glad, that they will repair it to the future
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

I just followed the '+ Create' process and selected the available home or Team folder. For Team Folders...
Replies
8
Views
2,730
  • Question
OK, thanks for your help! Deletion from NAS #recycle even if in a Team Folder seems to only affect...
Replies
2
Views
2,243
Yah, that's what I originally enquired about. But that was before proceeding through with setting up the...
Replies
6
Views
5,294
Ah, I never thought that some of the content in that folder could be preventing it from being shared. I...
Replies
2
Views
3,606
Yes i understand I will try to write them Thanks
Replies
12
Views
10,945
  • Question
I have 2 Windows 10 PC Clients that use Synology Drive to keep files synced between them. However, for...
Replies
0
Views
1,698
  • Question
Following thread too as 6 months ago I removed it on one NAS, and had no issues?
Replies
5
Views
656

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top