I'm using unRAID 6.9.

I have 2 pools: cache, and lone, each one with only 1 disk.

I tried for the first time to create a share (see screenshot) using the cache pool lone, but I have been unable to.

This is the error I see in the syslog:

 

May 15 14:16:11 Tower emhttpd: shcmd (1409): mkdir '/mnt/user/public'
May 15 14:16:11 Tower root: mkdir: cannot create directory '/mnt/user/public': No medium found
May 15 14:16:11 Tower emhttpd: shcmd (1409): exit status: 1
May 15 14:16:11 Tower emhttpd: shcmd (1410): rm '/boot/config/shares/public.cfg'

 

If I create a share using the array disks it just works.

I already tried several things, stopping-starting the array, restarting the server, creating the share using the other pool named cache, but nothing. I also search the forum for solutions, found similar threads, but all of them without a useful answer.

 

Why can't I create a pool-only share?

tower-diagnostics-20210515-1422.zip

Edited June 13, 20215 yr by stealth82
Marked as solved

You've got corruption on disk #1.  Wait for a btrfs guy ( @JorgeB ) to pipe in

Yeah, that's a separate problem that just popped out now as I went through a cycle of stop start array, and there it was, a nice surprise...

I recovered the data, though I am not sure something got corrupt..., and reinitialized the drive, I will have to copy data back to it.

 

I tried to change from cache only to cache prefer and I was finally able to create the shares. Only... it's now writing exclusively to disk1 of the array and never to the pool. Moreover I have data in the pool disk that should fall under the user share and it doesn't show anything!! What's going on???

tower-diagnostics-20210515-1853.zip

Edited May 15, 20215 yr by stealth82

Not quite sure right now.  But, you also want to stop exposing the SSH port directly to the internet.  Not a great idea unless you know what you're doing.

😞

 

I'll keep on trying.

 

Regarding the ssh, yes, it's hardened and root is not password enabled from outside.

Edited May 15, 20215 yr by stealth82

OK, I believe it's the same problem. It's writing on disk1 because it can't do it in any of the pools.

That's why the only-cache type of share can't be created whereas the prefer does; it's able to create it on disk1 of the array while failing to do it on the pool disk but at least it can "deal with that".

 

At the same time shfs - is this the process that shows all the disk folders as one under /mnt/user, right? - isn't able to read data from any of the pool disk directories. And yet the webGUI is able to show it (see attached screenshots).

 

Edited May 15, 20215 yr by stealth82

OK, I solved the problem:

 

Thank you @Squid 😉, that was the answer!

 

There also some data corruption detected on disk4:

 

May 15 11:38:32 Tower kernel: BTRFS info (device md4): bdev /dev/md4 errs: wr 0, rd 0, flush 0, corrupt 25, gen 0

 

You can run a scrub to identify any corrupt data, also good idea to run a memtest.

I had noticed that but thank you for pointing it out. That happened on a new disk I installed just the other day to replace one that started counting pending sectors last week. In conjunction with that I shrank the array by reassigning the pulled drive as a pool drive. So there’s been a lot of moving/copying while parity was also rebuilding. I think I should have gone for a less reckless approach and do things in sequence rather than in parallel…

 

I started the scrub process now. Hope everything will turn out well…