(SOLVED) No Disk Space Issue

[SmokeyColes]

Hello, on drive 3 - I have 2.5TB free on a 6TB xfs hdd.  

I have a share called "Movies" it only includes disk 3 and as a minimum set at 100MB (changed from 0kB)

I am trying to copy files from SMB (513GB and it is not able due to not enough free space).

I have rebooted.  

 

There is a post which says using Krusader may somehow double account storage.  Whilst backing up my QNAP - I decided to use Krusdar with a QNAP smb mount point, into the drive.  I am currently unsure if I went direct to disk3 or to the user folder > Movies.

 

What I haven't got from the posts I read, is how to correct and fix the issue without a format. 

 

Can any one help out how to fix issue?

 

The frustrating this is Krusader allows me to still copy the 513GB to the hdd through User > Movies from my QNAP SMB share).

 

I really would prefer not having to transfer all data from the QNAP again (it has been fairly slow).

Can anyone help?

 

Thanks

Chris

 

Edited May 4, 2021 by SmokeyColes

[SmokeyColes]

Hi

 

I used unbalance to move to disk 2; I then erased and formatted disk 3.  I shared disk 2 and 3 and now have 1.81TB free on disk 2m and 3.14TB on disk 3. 

I have continued to move files and encountered the error again for a directory at 400GB.

 

In addition I have not heard back from Unraid support.  I am at a loss. 

My trial ends in 12 days and this is a deal breaker for me, I really need to be able to utilise the space on the drives. 

 

Does anyone know what is going wrong?

The only change from my share above is that it now includes DISK 2 and DISK 3.

 

*** UPDATE *** when i map the share directly it works, i was using one called rootshare which was made in my SQL. 

Could this make a difference? I tried it a couple of times and get the same error through that share.   

I have a solution I guess, but not the understanding?

[rootshare] 
path = /mnt/user
comment =
browseable = yes
valid users = nas
write list = nas
vfs objects =

 

Edited April 29, 2021 by SmokeyColes

[JorgeB]

39 minutes ago, SmokeyColes said:

Could this make a difference?

Probably, why were you using a "rootshare"? That's not default behavior.

[SmokeyColes]

No its an SMB entry from one of SpaceInvaders very good videos.  When I connect to NAS I want to be able to see all my folders as I alternate between them all, with a single mount like my QNAP and my Thecaus.  I don't like having to setup multiple shares to each shared folder, but I want the shares individual to control and manage.  

This is sort of besides the point - i think. 

 

Why would it differ and give me space constraints writing within a share, through a mnt/user/ mount instead of a share mount?

Edited April 29, 2021 by SmokeyColes

[JorgeB]

No idea, it's not something that I ever tried.

[jonp]

Hi there,

 

Saw your emails into support.  Unfortunately I'm not super familiar with Krusader and how it may affect the storage space represented on the system.  If you try copying from a standard Windows or Mac machine, do you have these problems?  Exporting /mnt/user isn't currently supported functionality, and oddball behavior like this could be the result of it.  Why not just create one single share called "share" and use that one share?

[ljm42]

On 4/29/2021 at 8:49 AM, SmokeyColes said:

*** UPDATE *** when i map the share directly it works, i was using one called rootshare which was made in my SQL. 

 

The "root share" is a hack that bypasses all of Unraid's logic for how to place files on disks, how to handle permissions, etc. What is probably happening is that you have filled one disk and the "root share" doesn't know how to move on to the next disk. Skip the root share and use Unraid's shares instead.

[SmokeyColes]

On 5/3/2021 at 2:48 PM, jonp said:

Saw your emails into support.  Unfortunately I'm not super familiar with Krusader and how it may affect the storage space represented on the system.  If you try copying from a standard Windows or Mac machine, do you have these problems?  Exporting /mnt/user isn't currently supported functionality, and oddball behavior like this could be the result of it.  Why not just create one single share called "share" and use that one share?

 

Hi All

 

The problem was caused through Windows share, with the hack root share.

 

Though I appreciate the words hack, I didn't realise it bypassed most of UNRAIDs permissions.  It is actually very useful.. I am migrating a lot of data from a QNAP NAS and Thecaus NAS, my movies folder is 9TB on a RAID5.  So the root share and the disks share is really useful as i can specify which folders i want under which drive  before copying (6tb drives on my unraid NAS), for example all 1080p on one drive, then childrens & drama & documentary on another drive (its unlikely I'm going to switch between the two when selecting movies) so it prevent unnecessary spin up of the drive.  Essentially i'm trying to optimise the efficiency of how I will use plex and kodi.  So this is the use case and why its helpful.  When migrating lots of data (well for me - its a lot) and were talking about 22TB - it is handy to have this access with different size drives.

Similarly i don't want one share for all, as i like to separate tv shows, movies, software, documents etc.  Its not intended to be a frequent use thing, as I like to use and manage the shares and permissions.

 

However it sounds like I'm just working outside of the capability of Unraid using the root share and I thought it was OK having seen the video. 

So I have reverted back to having a lot of different shares in my Windows computer and doing it that way.  I am then using a plugin called "Unbalance" to move the folders to where I want them to go which doesn't encounter the issues I had on Krusader or Windows SMB using root share - the root share being the issue.  This is because unbalance uses the UNRAID shares directly.  I'm happy as it works, all be it - it is a super inefficient way of transferring data and then having to retransfer it between drives e.g. transfer to the share, then move folders from drive 3 to drive 2, then drive 2 to 3.  Some of these transfers are taking above seven hours for a couple of TBs then more hours from drive to drive.

 

Maybe in the future it may be considered, I am sure I can't be the only one wanting to do this and optimise how they migrate a lot of data choosing which disks it falls on.

I will also delete the 'hack' as I agree - its not any good, and clearly I've found issues with it when using multiple drives.

 

Thank you for getting back to me @jonp @ljm42

 

Edited May 4, 2021 by SmokeyColes

[JonathanM]

1 hour ago, SmokeyColes said:

I'm happy as it works, all be it - it is a super inefficient way of transferring data and then having to retransfer it between drives e.g. transfer to the share, then move folders from drive 3 to drive 2, then drive 2 to 3. 

Now that you have your feet wet, take a look at enabling disk shares. That will expose all the drives as shares.

 

Warning!! Disk shares are disabled by default for a reason. The user shares are a combination of all root folders on all the drives, so it's 2 different views of exactly the same files. If you mix user shares and disk shares in a file operation, you can corrupt data.