![]() browser client - doesn't see the folder in Team folder structure Disable and re-enable the "DOC" folder in Drive server Admin Console: Then it must be error at Drive Server sideĥ. ![]() when I try to CREATE new sync task, the folder "DOC" isn't visible in Team folder structure as was described above is running with "write privileges" error I can use filter of the Logs for the "DOC" folder = then I can see last folder "DOC" isn't visible in the Team folder structure Browser Drive client (FF, Chrome, Edge, Safari): Shared folder "DOC" Properties/Permissions:Ī) user (used for the Drive client s APPs) is visible and ALLOW for Read/Write, checked details = OK, doneī) doubled by Advanced options/Permission inspector = OK, doneĬ) Applied for sub-folder structure = to be sure, OK, doneģ. write (new file, folder) by same user is performed w/o issue. I can see filtered logs for the "DOC" folder, also written by SMB events in Today (also test files created in File station directly) no special settings in Users Sync Profiles defined for this folder 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) now I have just one hint, based on Win Drive client console = Account does not have write privileges (see in the picture below) the "DOC" folder is available by SMB/CIFS/NFS and no read/write troubles discovered the "DOC" folder has been used last time 2 weeks ago with expected sync, no troubles ![]() 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. 7 folders from 8 are running in normal operation (seen in Team folders structure in any devices/OSs/browsers also synced as expected) Multi OS Drive clients in operation, also web Drive clientĭrive desktop clients (Win/Ubuntu) in last ver But my theory is that these events when the disks were connected by ESATA, has caused the DS to "blacklist" these disks, as they have once caused "reset commands" due to flaky cables.Team folder contains 8 folders for the Drive services This was probably because of older unstable ESATA cables. First, I tried connecting the two problematic disks using the 2 ESATA ports of the DS1515+, but the disks did never appear in the storage manager, and I saw some reset/connection errors in the dmesg log (using the linux terminal). ![]() I suspect that the disks are rejected by the DS because of some historic data. So why is Storage Manager stuck on the Critical status?īoth disks work completely fine when connected to another computer, so I believe they are physically 100% OK. I've looked in the dmesg output from the linux terminal of the DS, with no errors for the disks that cause me trouble.īut I can see in all the extended views that no errors regarding reset/reidentification/reconnection etc have occurred. I've tried secure erasing one of the disks, with no luck. The error is "Multiple reset command errors have occurred.".įrom the Storage Manager, I cannot continue and the system won't let me intialize the disk to make it part of a storage pool. I have bought 3 of these drives, and 1 of them works fine and is now part of my storage pool, but the other 2 gives me an error when I install them in the DS. The hard drives are brand new Seagate Exos X. I am trying to install a new HDD in my DS1515+. ![]()
0 Comments
Leave a Reply. |