"Because to me, every "support" issue brought up in this thread is a valid "announcement" about that beta, giving users potentially critical information about the current beta, what works, what doesn't, and what problems users are having with it."

 

I agree with cohiba for the very same reason

 

 

I guess I'll put my 2 cents in..  I like having any questions or troubles people are having in the same thread as the announcement. Makes it easy for me to decide if I want to try this particular beta or not..

 

Phil

All fair points.

 

What i will do is just ignore completely all but the initial post. I really don't have the time to follow the various ramblings all bundled together into one amorphous blob.

 

As for the "one post to rule them all" theory... i couldnt disagree more... thats why there a forum with subjects and topics.

 

Im not going to labor the point only to say if i wanted to be in a chat room i would

 

Tom any chance you could have a discrete changelog to follow for those of us not wanting to read war and peace looking for the relevant bits?

 

 

It looks like a login prompt to me, just with some logging messages appended to your display...  Hit enter, and you should see the plain login prompt again.

 

SirWired

Can someone help me understand this please.

 

My rsync backups appear to be working with the new v4.3b6 release but I receive the following error for every file that is copied during the rsync session:

 

   rsync: chown "/mnt/user/backup/fs1/projects/nas/unraid/flash/user/packages/.readme.rtf.hx5pS6" failed: No such file or directory

 

Some observations:

 

1) I do not receive these errors if I roll back to v4.2 (I tested this today)

2) The dot in front of the file name doesn't really exist in the source or destination file, only in the error message

3) The dot.6 characters (".hx5pS6" in the example above) don't appear in the source or destination file, only in the error message

4) The dot.6 characters are unique for every file error message

5) I do not have a cache drive enabled in my configuration

 

It appears to me that v4.3 clearly handles files in a manner different from v4.2 and it is tripping up rsync.  I just don't understand enough about the changes from v4.2 to v4.3 to diagnose the issue.

 

Any info/insight is appreciated.

Are you using the user shares or direct disk shares?

I would suggest switching to the opposite just to check the issue.

 

the dot prefixed file is a temp file.

rsync first copies the file to a  dot prefixed temp file.

 

the format above is shown DURING a file copy

 

i.e. the file is named smth like that, WHILE it is going to the destination (at the destination) and when the file finishes, it gets renamed to its original name

 

so probably rsync created the list of files to sync while a file was copied (by you) and when rsync reached the file, that file of course was copied already so that temp filename was not there

 

 

Well, I am using user shares.  But it wasn't a problem until v4.3.  Here's the cron job I'm running once per day:

 

#!/bin/bash
#
# Title: *_blacky_rsync.sh
#
# Summary:
# The purpose of this script is to 'PULL' a backup off of a remote rsync server to a local destination on the client.
#

# rsync source
sSrc="blacky::fs1"

# rsync destination
sDest="/mnt/user/backup/fs1"

# rsync parameters
sParms="-amv --delete"
# -a archive mode; same as -rlptgoD (no -H preserve hard links)
# -rlptgoD
#	-r	recurss into directories
#	-l	copy symlinks as symlinks
#	-p	preserve permissions
#	-t	preserve times
#	-g	preserve group
#	-o	preserve owner (super-user only)
#	-D	same as --devices --specials
#		--devices	preserve device files (super-user only)
#		--specials	preserve special files
# -m prune empty directory chains from the file-list
# --delete	delete files that don't exist on the sending side

# Here's the magic:
rsync $sParms $sSrc $sDest

# My job here is done
exit

 

For the record I do not have the cache drive enabled at all.  However, I did test with a cache drive enabled and it did work however with the same exact error messages.  The files even went to the cache drive as their first stop prior to being written to the RAID volumes.  That was a good thing as it seems that the new cache feature might speed up my rsync's if I can fix the 'chown error' introduced with v4.3.

I would consider this an issue

 

root@unraid:/mnt/user/video# touch x.x
root@unraid:/mnt/user/video# ls -l x.x
-rw-r--r-- 1 root root 0 Apr 14 22:42 x.x
root@unraid:/mnt/user/video# chown root:root x.x
chown: changing ownership of `x.x': No such file or directory

This works fine

root@unraid:/mnt/user/video# cd /mnt/disk1/video
root@unraid:/mnt/disk1/video# ls -l x.x
-rw-r--r-- 1 root root 0 Apr 14 22:42 x.x
root@unraid:/mnt/disk1/video# chown root:root x.x
root@unraid:/mnt/disk1/video# 

Gone from 4.2.1 to 4.3-beta6 - ... - and everything works fine for me. The cache disk works well. Thank you! 

 

One minor annoyance with the cache drive:

 

When the moving to the real array is done, the cache drive ends up with a full directory tree with no contents in it. In my case I ended up with >30 empty directories on the cache drive. It's not really a critical issue, but it's not "nice". Wouldn't it be possible to delete the empty directories after a successful move of the cached data to the real array?

Wouldn't it be possible to delete the empty directories after a successful move of the cached data to the real array?

 

You can add something like this to the "mover" script, or just execute it by hand once in a while.

 

find /mnt/cache/* -depth -type d -empty -exec rmdir {} \;

 

Joe L.

Maybe there is a reason Tom leaves those in?

 

 

I would consider this an issue

 

root@unraid:/mnt/user/video# touch x.x
root@unraid:/mnt/user/video# ls -l x.x
-rw-r--r-- 1 root root 0 Apr 14 22:42 x.x
root@unraid:/mnt/user/video# chown root:root x.x
chown: changing ownership of `x.x': No such file or directory

This works fine

root@unraid:/mnt/user/video# cd /mnt/disk1/video
root@unraid:/mnt/disk1/video# ls -l x.x
-rw-r--r-- 1 root root 0 Apr 14 22:42 x.x
root@unraid:/mnt/disk1/video# chown root:root x.x
root@unraid:/mnt/disk1/video# 

 

So, do you think that there may be an issue with User Shares in the new version?

Looks like the chown command is not properly implemented in the user file system.

Agreed, and we also know that the userfs was re-written, so a few bugs or unimplemented features may exist.

Grats on beta6. Installed it on 4/2 with a 250GB cache disk and it has been up and running with zero downtime since then. What a huge difference the cache disk makes in the performance of the system. I love it.