I have a share (KodiMedia) that is spanned across multiple disks. This share is secured and only one user has write privilege to it. This user can write to this share with the exception of disk18: When the write is to disk18 I get a "disk is full" error. The disk has 578GB free.
The share has "Manual" for split level and I'm writing to a subfolder, so I know which disk should be written to.
When writing to a subfolder on a different disk there is no issue.
This happens also when I make the share public.
I ran "New Permission" for the share and for the disk and nothing changed.
Write to the disk share always ok.

Checked the xfs fs in maintenance mode and no issues reported.

Any advice?

 

 

Edited December 1, 20232 yr by Gico

You need to post up the Diagnostics file in a new post in this thread.  (Be sure it includes an attempt to write a file to this disk.  Giving the time of this failed attempt would also be helpful.)   Can we assume that writing to other folders/directories also fail? 

Diagnostics attached. I tried again to copy just now, December 1st 08:20 AM.
MoviesShahar A-F subfolders are on disk18, G-Z are on disk19, and exactly starting with G folders is where all copies are failing.

This issue occurs also in other folder (i.e. not MoviesShahar) that spans on disk18 and other disks, so definitely seems like disk related.

juno-diagnostics-20231201-0824.zip

5 hours ago, Gico said:

MoviesShahar A-F subfolders are on disk18, G-Z are on disk19, and exactly starting with G folders is where all copies are failing.

 

16 hours ago, Gico said:

 

I am confused here...

 

Plus, I don't think you have a "SMB Privileges Issue".  You have a problem writing to a specific disk on your server!  I did notice that in the left panel, you started with 'Network' and, in the right panel, you started from 'Quick Access'.  I would not think that makes a difference, but one never knows with Windows.  Do some more testing...

And please post up a screenshot of the 'Array Devices' section of the 'MAIN' tab.  You can black-out the Drive Serial numbers for privacy purposes. 

 

Are you using Active Directory (AD) by any chance? 

That share's floor is set to 585G, and disk18 has lees free space than that:

 

Filesystem      Size  Used Avail Use% Mounted on
/dev/md18p1     9.1T  8.6T  539G  95% /mnt/disk18

 

24 minutes ago, JorgeB said:

That share's floor is set to 585G, and disk18 has lees free space than that:

 

Filesystem      Size  Used Avail Use% Mounted on
/dev/md18p1     9.1T  8.6T  539G  95% /mnt/disk18

 

Obviously that was it. Forgot about this restriction 🙂. Many thanks

This is the problem with Split levels.  It can make for nice 'neat' file organization but it has some nasty side effects because of the order of precedence of the various parameters on where files are place on a share.  (I personally believe 'Split levels' should never be be used.

 

Now for my reasoning.  It was implemented many, many years ago when HD sizes were measured in GB.   Unraid had been designed originally for the storage of media.  At that time DVD's were the most common platform for media distribution.  The video files on DVD were restricted in size to 1GB (1,073,741,824 bytes)  and most movies were larger than that.  So the movies were broken up in a series of files (each one except for the last one being exactly 1GB)!   These files were intended to be merged together on the fly into a continuous stream of video during playback.  Unraid could do this except when the set of files was split across two HD's.  In that case, there would be a pause (from momentary to several seconds) in the playback.  (This pause could also be in the middle of a word!)  This situation was simply unacceptable.  Thus, the split level was introduced to prevent this situation and it still exists today. 

Admittedly having some OCD ("O" as in Order 😀) and being a control freak, the split level option is welcomed by my kind. Usually I don't rely on it, and I copy my media to disk shares, but in Kodi v20 a new artwork scraper plugin called Artwork Dump was introduced that regularly writes to the media folders, so this option is now important for me.

 

Also in the bad scenario of losing a disk / data (been there), I would rather know what I lost, so prefer it to be alphabetically organized, rather than every time that I need to know if a specific media exists, I'll have to open a spreadsheet.