I have a 3 drive array + 1 parity disk and 1 cache drive.  For a share that has cache=yes and a directory that hasn't been written to recently (seems like when the directory doesn't exist yet on /mnt/cache/), writes are initially "not supported" but then soon after become possible.  

 

EDIT: It's not a time delay.  It's only making one directory at a time on /mnt/cache/$share to match what is on /mnt/user/$share, see my test here

 

Arrays are Btrfs-encrypted, cache is xfs-encrypted, tons of free space on both, everything spun up.  This does not occur on shares with cache=no.  Ran some tools like Docker Safe New Permissions, no effect.  Reproducible by just going to a different directory that exists on the array but not in /mnt/cache yet.  Occurs in safe mode as well, diagnostics on latest post.

 

On 6.8.1

 

Quote

root@tower:/mnt/user/Archive# cd FamilyPhotoVideo/Kids/2020/
root@tower:/mnt/user/Archive/FamilyPhotoVideo/Kids/2020/# touch a
touch: cannot touch 'a': Operation not supported
root@tower:/mnt/user/Archive/FamilyPhotoVideo/Kids/2020/# touch a
touch: cannot touch 'a': Operation not supported
root@tower:/mnt/user/Archive/FamilyPhotoVideo/Kids/2020/# touch a
touch: cannot touch 'a': Operation not supported
root@tower:/mnt/user/Archive/FamilyPhotoVideo/Kids/2020/# touch a
root@tower:/mnt/user/Archive/FamilyPhotoVideo/Kids/2020/# #success

Windows via smb says:

 

Diagnostics:

tower-diagnostics-20200118-1549.zip

 

Edited January 24, 20206 yr by robobub

Nothing really obvious I see, but this is an abnormality:

gcrypt:bucket     1.0P   13T  1.0P   2% /mnt/user/remote/gdrive

General rule is that you should never mount anything within /mnt/user because that is for unRaid to manage 

Thanks, will update that.  Was just a temporary lazy way of having it dynamically SMB exported without modifying smb-extra.conf.  Better ideas welcome, I am new to unRAID.  Out of curiosity I did see if it helped the "not supported" issue but unfortunately not.

So after a few tests, here's what's occuring.  It's not a time delay.  It's only making one directory at a time on /mnt/cache/$share to match what is on /mnt/user/$share

 

What could possibly be causing this? Persisted across reboots.  After this next preclear, I'll be running in safe mode without plugins to see if it still occurs.

 

Test command: while (true); do tree /mnt/cache/Archive; touch a; tree /mnt/cache/Archive; echo "Sleeping for 5 seconds..."; sleep 5; done

Quote

root@tower:/mnt/user/Archive/1/2/3/4/5/6/7/8/9# while (true); do tree /mnt/cache/Archive; touch a; tree /mnt/cache/Archive; echo "Sleeping for 5 seconds..."; sleep 5; done
/mnt/cache/Archive [error opening dir]

0 directories, 0 files
touch: cannot touch 'a': Operation not supported
/mnt/cache/Archive

0 directories, 0 files
Sleeping for 5 seconds...
/mnt/cache/Archive

0 directories, 0 files
touch: cannot touch 'a': Operation not supported
/mnt/cache/Archive
└── 1

 

# [... multiple loop executions, one for each directory]

 

Sleeping for 5 seconds...
/mnt/cache/Archive
└── 1
    └── 2
        └── 3
            └── 4
                └── 5
                    └── 6
                        └── 7
                            └── 8

8 directories, 0 files
touch: cannot touch 'a': Operation not supported
/mnt/cache/Archive
└── 1
    └── 2
        └── 3
            └── 4
                └── 5
                    └── 6
                        └── 7
                            └── 8
                                └── 9

9 directories, 0 files
Sleeping for 5 seconds...
/mnt/cache/Archive
└── 1
    └── 2
        └── 3
            └── 4
                └── 5
                    └── 6
                        └── 7
                            └── 8
                                └── 9

9 directories, 0 files
/mnt/cache/Archive
└── 1
    └── 2
        └── 3
            └── 4
                └── 5
                    └── 6
                        └── 7
                            └── 8
                                └── 9
                                    └── a

9 directories, 1 file

So, after touching a file, it makes the first missing directory instantly.  After 5 seconds, you can see no more have been made. 

 

Full output of that command:

20200119_unraid_cache_write_issue.log

 

Edited January 24, 20206 yr by robobub

Indeed this still occurs in safe mode with all plugins disabled.  Any ideas or troubleshooting steps?  diagnostics from safe mode:

 

tower-diagnostics-20200119-2337.zip

Has no one experienced this with Btrfs-encrypted array drives ad a xfs-encrypted cache drive with a cache=yes share?

 

Importing any files with many programs is a major pain, as any initial files are error'd out, requiring me to have to manually re-import those selected files.

Edited January 21, 20206 yr by robobub

Should I cross-post this to bug reports or pre-sales support? I'd like to find a solution before my trial runs out.

Edited January 23, 20206 yr by robobub

I would do it as a bug report