Hi guys,

 

I recent moved some file around in the disk share rather than the user share because I did not want unRaid to have to recopy the data that was already on the disk.

 

Apparently that causes really big errors. Can anybody help me fix this? Syslog attached.

 

As you can see at the end, I was trying to run Plex, but it failed because of errors.

 

Im running 5.0rc10

 

I moved files from /mnt/disk2/TV to /mnt/user/Other\ TV.

 

In effect I was trying to move these files from the TV user share to the Other TV user share (since they are on the same disk)

 

When I tried to build my Plex library, Plex just quit and I got the following syslog above.

I just tried rebooting and doing this again, but got the same errors. (attached)

 

I am getting major errors

 

Jan 18 09:10:41 Harvard logger:  xml parse error (Errors)

Jan 18 09:48:09 Harvard kernel: Plex Media Scan[6590]: segfault at 7e ip b5bcfdf3 sp b543bfe4 error 4 in libc-2.11.1.so[b5b5d000+15c000] (Errors)

 

and I am also getting many duplicate item errors. ie

 

Jan 18 09:17:00 Harvard shfs/user: duplicate object: /mnt/disk2/TV/Luck/.AppleDouble/.Parent (Minor Issues)

 

It also looks like I am getting share errors ie

 

Jan 18 10:59:47 Harvard emhttp: get_filesystem_status: statfs: /mnt/user/Education Transport endpoint is not connected (Other emhttp)

syslog-2013-01-18.txt.zip

syslog-2013-01-18_1.txt

Hi guys,

 

I recent moved some file around in the disk share rather than the user share because I did not want unRaid to have to recopy the data that was already on the disk.

 

Apparently that causes really big errors. Can anybody help me fix this? Syslog attached.

 

As you can see at the end, I was trying to run Plex, but it failed because of errors.

 

Im running 5.0rc10

 

I moved files from /mnt/disk2/TV to /mnt/user/Other\ TV.

 

In effect I was trying to move these files from the TV user share to the Other TV user share (since they are on the same disk)

 

When I tried to build my Plex library, Plex just quit and I got the following syslog above.

I just tried rebooting and doing this again, but got the same errors. (attached)

 

I am getting major errors

 

Jan 18 09:10:41 Harvard logger:  xml parse error (Errors)

Jan 18 09:48:09 Harvard kernel: Plex Media Scan[6590]: segfault at 7e ip b5bcfdf3 sp b543bfe4 error 4 in libc-2.11.1.so[b5b5d000+15c000] (Errors)

 

and I am also getting many duplicate item errors. ie

 

Jan 18 09:17:00 Harvard shfs/user: duplicate object: /mnt/disk2/TV/Luck/.AppleDouble/.Parent (Minor Issues)

 

It also looks like I am getting share errors ie

 

Jan 18 10:59:47 Harvard emhttp: get_filesystem_status: statfs: /mnt/user/Education Transport endpoint is not connected (Other emhttp)

 

The duplicate is normal whenever you move files. The file will first be created and then the source will be deleted, no need to worry about those.

 

The segfault happened in Plex, try to turn if off and see if it comes back, also ask the creator of the plugin and the plex guys themselves help.

 

Since all was working before my guess is that Plex caused a segfault that crashed smbd or another component... A reboot will fix it..

 

I do not see you mentioning filesystem errors by the way.

 

Thank you for your reply,

 

I guess I didn't know what to call it and I thought it was related to the filesystem. Im kind of a noob.

 

Also, I have rebooted three times now and I keep getting these same errors over and over again. So I am not sure what to do.

 

I would gladly move this to the Plex thread, but I think that something else is causing Plex to fail.

I recent moved some file around in the disk share rather than the user share because I did not want unRaid to have to recopy the data that was already on

 

I moved files from /mnt/disk2/TV to /mnt/user/Other\ TV.

Let's step through this. My understand is that you would have wanted to move files from /mnt/disk2/TV to /mnt/disk2/Other/TV in order to not have recopied the data. Can you re-confirm which paths you used?

 

Yes, those are the paths I used, except I moved it to mnt/disk2/Other TV, not Other/TV. I said Other\ TV because that is how it works in the code.

 

I did this inside of Finder on my macbook.

you will continue to see the duplicates because a transfer was broken, you need to look at the disk shares individually and manually deleted one of both (check which one is correct, not necessarily both !!)

 

I would stop with plex, fix this first and see if things are stable, they should..

Yes, those are the paths I used, except I moved it to mnt/disk2/Other TV, not Other/TV. I said Other\ TV because that is how it works in the code.

 

I did this inside of Finder on my macbook.

 

I wanted to make sure as in your OP you stated "I moved files from /mnt/disk2/TV to /mnt/user/Other\ TV. So want to clarify if you went from one directory on disk 2 to another directory on disk 2, Or you went from disk 2 to \User (which is a difference, and explanation for everything else depends on which you did).

 

Example, A cut and paste from one dir to another on the same disk would not cause dupe files. However if you moved from disk 2 to \user\other dir (but disk 2 is apart of the user share) you would receive dupe file messages...

I have also seen mover fails to complete a move, where it copies over the files to the array but fails to delete them off the cache drive. Dupe files are logged and unless you remove them either from the cache drive or array, you will keep receiving the messages.

Hi guys,

 

I recent moved some file around in the disk share rather than the user share because I did not want unRaid to have to recopy the data that was already on the disk.

 

Apparently that causes really big errors. Can anybody help me fix this? Syslog attached.

 

As you can see at the end, I was trying to run Plex, but it failed because of errors.

 

Im running 5.0rc10

 

I moved files from /mnt/disk2/TV to /mnt/user/Other\ TV.

 

In effect I was trying to move these files from the TV user share to the Other TV user share (since they are on the same disk)

 

When I tried to build my Plex library, Plex just quit and I got the following syslog above.

I just tried rebooting and doing this again, but got the same errors. (attached)

 

I am getting major errors

 

Jan 18 09:10:41 Harvard logger:  xml parse error (Errors)

Jan 18 09:48:09 Harvard kernel: Plex Media Scan[6590]: segfault at 7e ip b5bcfdf3 sp b543bfe4 error 4 in libc-2.11.1.so[b5b5d000+15c000] (Errors)

 

and I am also getting many duplicate item errors. ie

 

Jan 18 09:17:00 Harvard shfs/user: duplicate object: /mnt/disk2/TV/Luck/.AppleDouble/.Parent (Minor Issues)

 

It also looks like I am getting share errors ie

 

Jan 18 10:59:47 Harvard emhttp: get_filesystem_status: statfs: /mnt/user/Education Transport endpoint is not connected (Other emhttp)

 

The command "mv /mnt/disk2/TV /mnt/user/Other\ TV" will keep TV on disk 2 regardless of share settings unless you have a cache drive. Do you have a cache drive? To move a file off of a disk the destination disk must be specified or a cache drive must active for the destination user share. Did you drag and drop in OS X to do the move or use the command line on the server?

 

The duplicates were added by OS X when the disk share was mounted in the Finder. The originals are on disk1 or possibly the cache drive. Mounting a user share merges the directories on all of the disks. When the disk share was opened the original was not visible and so OS X created a new one. You can safely delete all of the .Appledouble files. The following command should delete them all:

 

 find / -name ".AppleDouble" -depth -exec rm -Rf {} \;

 

Post in the User Customizations forum to get help on the plex issue. It's unlikely that a person with the requisite expertise will see your post here.

 

The command "mv /mnt/disk2/TV /mnt/user/Other\ TV" will keep TV on disk 2 regardless of share settings unless you have a cache drive. Do you have a cache drive? To move a file off of a disk the destination disk must be specified or a cache drive must active for the destination user share. Did you drag and drop in OS X to do the move or use the command line on the server?

 

When you use MV in console on the unraid system itself, or whenever you use MC from console, then the cache drive is not used, cache drive is only used when writes are beiing done from an external system mounting the shares..

 

So the files will remain on disk2.

 

When you use MV in console on the unraid system itself, or whenever you use MC from console, then the cache drive is not used, cache drive is only used when writes are beiing done from an external system mounting the shares..

 

So the files will remain on disk2.

 

Not true.  If you use a shell to copy files to /mnt/user/some-share-name and that share uses cache drive, it will copy to cache drive if everything else permits it (e.g., split level, etc).

 

Bear in mind the shell is run as user 'root' and you will need to either use 'su' to run the command as user 'nobody' or use 'chmod/chown' to fix permissions afterwards.

 

Example,

 

su nobody -s /bin/bash -c "touch /mnt/user/some-share-name/afile"

When you use MV in console on the unraid system itself, or whenever you use MC from console, then the cache drive is not used, cache drive is only used when writes are beiing done from an external system mounting the shares..

 

So the files will remain on disk2.

 

Not true.  If you use a shell to copy files to /mnt/user/some-share-name and that share uses cache drive, it will copy to cache drive if everything else permits it (e.g., split level, etc).

 

Bear in mind the shell is run as user 'root' and you will need to either use 'su' to run the command as user 'nobody' or use 'chmod/chown' to fix permissions afterwards.

 

Example,

 

su nobody -s /bin/bash -c "touch /mnt/user/some-share-name/afile"

 

What about "newperms /mnt/user/some-share-name/afile"?

When you use MV in console on the unraid system itself, or whenever you use MC from console, then the cache drive is not used, cache drive is only used when writes are beiing done from an external system mounting the shares..

 

So the files will remain on disk2.

 

Not true.  If you use a shell to copy files to /mnt/user/some-share-name and that share uses cache drive, it will copy to cache drive if everything else permits it (e.g., split level, etc).

 

Bear in mind the shell is run as user 'root' and you will need to either use 'su' to run the command as user 'nobody' or use 'chmod/chown' to fix permissions afterwards.

 

Example,

 

su nobody -s /bin/bash -c "touch /mnt/user/some-share-name/afile"

 

What about "newperms /mnt/user/some-share-name/afile"?

You can do that as well (that would be the 'chmod/chown' method).  However... this script was created primarily for two purposes:

 

1. When upgrading from 4.7 to 5.0.  In all unRaid releases up to and including 4.7, all files and directories were given permissions '700', and all file operations, whether via Samba or command line, were done as the 'root' user.  However in 5.0 in order to support a better security model, it is necessary to let file operations operate on all permission bits (owner/group/other) instead of just (owner).  In addition, we want to get rid of root access for a number of reasons, one of which is that netatalk (AFP) does not permit a 'root' user.  So the 'newperms' script is designed to "replicate" the current set of (user) permissions to (user/group/other), preserving if a file read/write or read/only.  Also in 4.7 the three 'x' bits were used to map dos hidden/system/archive bits.  Well this is no longer done in 5.0, so we also want 'newperms' to clear the 'x' bits (unless it's a directory, in which case the 'x' bits have to be set).  This latter action is sometimes undesirable, for example, if you have a linux executable file (on purpose), it will be come un-executable after running 'newperms'.

 

2. The purpose of the script is to get permissions/ownership back to "standard way of doing things" after switch from Active Directory back to "normal".  This is because AD will set crazy values for uid/gid which only have context in an AD environment.