Reply
Regular Visitor
Gordy999
Posts: 4
Registered: ‎04-27-2011
0

Re: How to gain access on .tb folders & files on my Seagate NAS 220 Blackarmor​?.

No kidding.  This thread looks like it has been marked resolved.  This issue is not resolved.

Byte
Crowley
Posts: 6
Registered: ‎05-05-2011
0

Re: How to gain access on .tb folders & files on my Seagate NAS 220 Blackarmor​?.

any update on a fix for this

 

Visitor
Flatsi
Posts: 3
Registered: ‎05-18-2011

Re: How to gain access on .tb folders & files on my Seagate NAS 220 Blackarmor​?.

My first post on this seems to have worked for me, i now have full access too all my folders.

 

Just a note though, the transfer speed of copying from the Nas TO the Nas was massively painfull.  I found it a lot faster to copy all (or in sections depending on local free space) to my pc and then back to the new share.   I am talking a few kb per sec when copying from Nas to Nas, not Mb per sec which i got when transfering to and from my pc.

 

I have now rid my self of the share with the corrupt rights on it.

 

p.s. Seagate.... this is not a fix so is still unresolved!

Byte
Crowley
Posts: 6
Registered: ‎05-05-2011
0

Re: How to gain access on .tb folders & files on my Seagate NAS 220 Blackarmor​?.

The lack of response from Seagate on this is somewhat disappointing, this should not be that big a deal to provide a fix

Byte
wondermike
Posts: 5
Registered: ‎06-11-2011
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

Hello, I just invested a couple hundred Euros into a brand new BlackArmor NAS and in many cases I can't delete folders from (please note) MY directory tree. Can someone help me?

Thanks

Michael

Visitor
e_ingemann
Posts: 1
Registered: ‎11-10-2011
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

Hi All,

 

I have the same problem, and copying between shares is not an option, too large data amounts. I have not found any fix by now, but I found that it is possible to cut and paste the .tb folders between folders on the same share. So what I have done is:

 

While doing reorg, remove Media Service on the share.

 

Make a folder in the root of the share in the hidden .tb folder, then cut and paste the .tb folders from the subfolders you need to delete into the folder created in the .tb root folder, rename the folder every time you copy to avoid conflicts.

 

Remember it is not visible from your Media Service devices reading from the share. 

 

Once the .tb folder has been moved and renamed to the new folder, you can delete the folder you need to delete.

 

It is not a pretty workaround, but it does make you able to delete folders in the foldertree.

 

Once you have finished doing your work, you can enable Media Service again.

 

Good luck!

 

Byte
CopaDon
Posts: 11
Registered: ‎12-09-2011
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

This sounds like exactly what I need. I see that I can move these folders around, but I'm still having trouble deleting them. Can you post a step-by-step method for getting rid of these files and folders? Your solution sounds like it will work, but the steps aren't clear. Thanks!

Regular Visitor
cap3344
Posts: 5
Registered: ‎08-01-2010
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

This is now months old and many posts on this subject.  Is there any official Seagate response?  Any ETA?

Byte
CopaDon
Posts: 11
Registered: ‎12-09-2011
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

It ended up being fairly simple to apply the SSH Mod from another post and delete them from the command line. You have to be somewhat UNIX-aware, however.

Regular Visitor
cap3344
Posts: 5
Registered: ‎08-01-2010
0

Re: You need permission from unix\ROOT to delete..... - Permissions issue on BA 440

I vaguely recall a CHMOD post, but I need to SSH connect to the NAS and then play the UNIX commands?  I have done some LINUX and have some familiarity with file management under UNIX.