Some shares on /mnt/user/ are empty. When I ssh in and look at /mnt/user0/ I can find my files. What could have caused this?

 

/mnt/user/ = All shares & files

/mnt/user0/ = All shares & files EXCEPT those on the cache.

 

/mnt/user/ = All shares & files

/mnt/user0/ = All shares & files EXCEPT those on the cache.

Unless the OP has user and user0 mixed up, doesn't explain what he's describing

 

Would be wise to post the full diagnostics if the description as described in the OP is correct

/mnt/user/ = All shares & files

/mnt/user0/ = All shares & files EXCEPT those on the cache.

Unless the OP has user and user0 mixed up, doesn't explain what he's describing

 

Would be wise to post the full diagnostics if the description as described in the OP is correct

 

Yeah, I assumed he'd got it mixed up.

That I knew about /user and /user0. That is not the problem.

 

With no files added, and no changes, the SHARE shows no files.

 

The looking at /user and /user0 were to verify that my files were still there. Shouldn't the share show files regardless of which /user directory it is in?

 

Again - the look at the 2 /user directories was to look for the files. It is the share that is not showing ANY files.

What are the share settings you've got for rot-temp, and like Squid says, post diagnostics.

Also, since you are consistently referring to this as /mnt/usr, just thought a correction would be in order in case it might help prevent a mistake in the future.

 

It is /mnt/user

 

Wouldn't want you to put a nonexistent path in a docker mapping for example.

 

no problems noted in Squid's plugin other than cache drive not happy.

 

System is in a parity check, so I'll wait until it is done to run any other diags that you link me to.

And so sorry that my fingers are stuck with not adding the e. It's what my fingers are used to.

 

 

...other than cache drive not happy.

This is probably the key.  Cache drive issues do royally affect the entire user share system.

 

Running the diagnostics (tools - diagnostics) isn't going to affect the parity check currently in progress.

And to make everyone happy I'll edit my posts to add the e.

Thank you Squid.

 

If it is the cache, I would guess that I could stop parity, turn off cache (nothing critical on it right now), then re-run parity.

 

Thank you Squid.

 

If it is the cache, I would guess that I could stop parity, turn off cache (nothing critical on it right now), then re-run parity.

Nothing dealing with the cache drive is ever going to affect a parity check.  Rather than be hasty, just post the diagnostics with parity running and people here can address the problems you're having

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

I actually rather liked it.  Kept CHBMB, and trurl on their toes since it was obviously a typo rather than a misunderstanding on your part 

And yes I know I'm full up. I'm in the middle of a purge and ordering some more 6tb drives.

tower-diagnostics-20161105-0938.zip

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

I actually rather liked it.  Kept CHBMB, and trurl on their toes since it was obviously a typo rather than a misunderstanding on your part 

It was not "obviously" a typo, since it was consistently wrong as I mentioned.

 

Now that it has been fixed in the OPs this digression is pointless.

Its the cache drive.

 

Started out here:

Nov  5 00:03:21 Tower kernel: ata5.00: exception Emask 0x0 SAct 0xc SErr 0x0 action 0x6 frozen
Nov  5 00:03:21 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED
Nov  5 00:03:21 Tower kernel: ata5.00: cmd 61/00:10:78:46:fa/02:00:04:00:00/40 tag 2 ncq 262144 out
Nov  5 00:03:21 Tower kernel:         res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  5 00:03:21 Tower kernel: ata5.00: status: { DRDY }
Nov  5 00:03:21 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED
Nov  5 00:03:21 Tower kernel: ata5.00: cmd 61/00:18:78:48:fa/02:00:04:00:00/40 tag 3 ncq 262144 out
Nov  5 00:03:21 Tower kernel:         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  5 00:03:21 Tower kernel: ata5.00: status: { DRDY }
Nov  5 00:03:21 Tower kernel: ata5: hard resetting link
Nov  5 00:03:31 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:03:31 Tower kernel: ata5: hard resetting link
Nov  5 00:03:41 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:03:41 Tower kernel: ata5: hard resetting link
Nov  5 00:03:52 Tower kernel: ata5: link is slow to respond, please be patient (ready=0)
Nov  5 00:04:16 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:04:16 Tower kernel: ata5: limiting SATA link speed to 3.0 Gbps
Nov  5 00:04:16 Tower kernel: ata5: hard resetting link
Nov  5 00:04:22 Tower kernel: ata5: softreset failed (device not ready)

Which implies a sata and/or power connection to the drive, but ultimately the driver just plain gave up and dropped the drive

Nov  5 00:04:22 Tower kernel: ata5: reset failed, giving up
Nov  5 00:04:22 Tower kernel: ata5.00: disabled
Nov  5 00:04:22 Tower kernel: ata5: EH complete

 

And then it more or less went down hill from there...

 

Since the cache drive is very intimate with the user system (but not user0), any time it drops unexpectedly will mess up user shares

 

You're going to have to at least check and reseat all connections to the drive at both ends.

would it be better to

 

wait for parity to end then power down and check connection?

 

or

 

stop parity check, disable cache, run parity, then power down to reset?

 

Wonder what could have killed the cache, as the system hasn't been touched.

would it be better to

 

wait for parity to end then power down and check connection?

 

or

 

stop parity check, disable cache, run parity, then power down to reset?

 

Wonder what could have killed the cache, as the system hasn't been touched.

The cache drive isn't involved in parity check operations, so doesn't particularly matter on that score when you do it.  Its really a question of

 

- The extra time involved in restarting the parity check

- How soon you need the apps (docker) to be back running properly again.

well, since files on shares have gone away and i can't work on them I'll stop parity and disable cache. Cache is nice but not critical.

 

ETA: disabled cache drive, rebooted, shares appeared.

 

THANKS!