Hi,

 

I've been moving my old data gradually during the last week and I noticed some strange behaviour with the user shares.

 

The first small annoyance was that after adding a new disk, the drive assignment slots changed. Luckily I wrote down which disk was assigned to which slot before, so reassigning them in the correct order was quick enough. It would be handy if unRAID actually remembered the disk assignments according to their IDs instead of whichever order the RAID controller assigns them. But I digress.

 

The real issue I have is with the user shares. Because the drive assignment changed the array was not initially started. After doing disk reassignments I started it myself, but none of the shares were restored except for one. To make things even stranger, even if I added a user share manually afterwards, it would not show the files from the respective disks in the array, but instead appears blank.

 

The most puzzling part is that I could still copy the files into this one user share that was showing up, but the files weren't actually copied onto any of the drives. I checked the status while I was copying and the parity disk was spun down, and the reads/writes were not changing on any of the other drives. The flash drive was idle as well. This leads me to believe that the file was actually being created in RAM. A look at free memory indicated that this is probably correct.

 

The only way to get the user sharing working again was to restart the machine completely, and have unRAID create all the user shares during boot. Just to be sure that it wasn't a one-time fluke I tried rearranging disks again so that the system powers up with the array stopped, then start it manually, and the same thing happened again. In fact this happened over and over again as I kept on adding more HDDs.

 

So on to the questions... firstly, is this expected behaviour? Will user shares not work correctly unless they have been successfully created during the boot process with the array correctly started up?

 

Secondly, why is it that one of the user shares still appears even if none of the other ones do? The only real difference I could find between that share and all others is that it has the split level set to ZERO.

 

Finally, will user permissions have any impact on the visibility of files within shares? I remember that changing these around made files appear and disappear from user shares. What is the "correct" mask for files and folders?

 

Thanks a lot for the help. I'm still a beginner with unRAID but I hope I'm going to pick up all the subtleties as quickly as possible

This is definitely not expected behavior.  You don't need a RAID controller with unRAID.  If you are using one, it should be set to JBOD or some other non-RAID setting.  I'm guessing that your RAID controller is taking over and trying to manage your disks for you.  Perhaps your RAID controller has a cache (and that is where the files are going).

 

Please outline your system for us (motherboard, expansion cards, etc.).  Also, please post a syslog.  Instructions are in the wiki under 'troubleshooting'.

 

The expected behavior is that unRAID should maintain disk assignments even after new disks are added.  Also, shares should persist across all kinds of hardware and software changes.  Everything you have described is not normal unRAID behavior.

 

I'm not sure I understand your 'user permissions' question.  Are you talking about User Level Security?  With this unRAID feature you can make certain shares accessible only with a password, or read-only for certain users, etc.  Individual files shouldn't appear and disappear.  However, you can set certain shares to only be accessible to certain users (although they should be visible or hidden for all users, there's no way to set a share as hidden for some and visible for others as far as I know).

Hi, thanks for the initial feedback. I know I don't need a RAID controller with unRAID, but unfortunately my motherboard comes in a 2+4 port configuration where 4 of the ports are connected to an on-board raid controller. I have set it up in the way that it identifies disks individually instead of starting up a RAID array, but based on some forum posts on Zotac, the controller wasn't really built for this and doesn't support it without bugs. For example, the last connected disk doesn't respond to SMART commands, and the RAID controller grinds to a halt if I connect a jumpered advanced format HDD that hasn't been formatted.

 

The motherboard in question is Zotac NM10-DTX and it looks to me like it's another good candidate to be added to the list of unsupported motherboards on the wiki. I don't have any other expansion cards, everything is connected directly to the motherboard itself.

 

I have attached the syslog which can hopefully shed some light on the issues that I am encountering.

syslog.zip

Another interesting problem is that I can't seem to be able to stop the array from the web interface. unMenu's stop array function works, but unRAID's own doesn't.

Here is what the syslog contains when I try stopping it:

 

 

Oct 14 17:51:41 Tower emhttp: shcmd (22): /etc/rc.d/rc.samba stop | logger
Oct 14 17:51:41 Tower emhttp: shcmd (23): /etc/rc.d/rc.nfsd stop | logger
Oct 14 17:51:42 Tower emhttp: Spinning up all drives...
Oct 14 17:51:42 Tower emhttp: shcmd (24): sync
Oct 14 17:51:42 Tower kernel: mdcmd (19): spinup 0
Oct 14 17:51:42 Tower kernel: mdcmd (20): spinup 1
Oct 14 17:51:42 Tower kernel: mdcmd (21): spinup 2
Oct 14 17:51:42 Tower emhttp: disk_temperature: ATTR_Temperature_Celsius not found
Oct 14 17:51:42 Tower emhttp: shcmd (25): umount /mnt/user >/dev/null 2>&1
Oct 14 17:51:42 Tower emhttp: _shcmd: shcmd (25): exit status: 1
Oct 14 17:51:42 Tower emhttp: shcmd (26): rmdir /mnt/user >/dev/null 2>&1
Oct 14 17:51:42 Tower emhttp: _shcmd: shcmd (26): exit status: 1
Oct 14 17:51:42 Tower emhttp: Retry unmounting user share(s)...
Oct 14 17:51:47 Tower emhttp: disk_temperature: ATTR_Temperature_Celsius not found
Oct 14 17:51:47 Tower emhttp: shcmd (27): umount /mnt/user >/dev/null 2>&1
Oct 14 17:51:47 Tower emhttp: _shcmd: shcmd (27): exit status: 1
Oct 14 17:51:47 Tower emhttp: shcmd (28): rmdir /mnt/user >/dev/null 2>&1
Oct 14 17:51:47 Tower emhttp: _shcmd: shcmd (28): exit status: 1
Oct 14 17:51:47 Tower emhttp: Retry unmounting user share(s)...
Oct 14 17:51:48 Tower emhttp: disk_temperature: ATTR_Temperature_Celsius not found
Oct 14 17:51:50 Tower last message repeated 2 times
Oct 14 17:51:52 Tower emhttp: shcmd (29): umount /mnt/user >/dev/null 2>&1
Oct 14 17:51:52 Tower emhttp: _shcmd: shcmd (29): exit status: 1
Oct 14 17:51:52 Tower emhttp: shcmd (30): rmdir /mnt/user >/dev/null 2>&1
Oct 14 17:51:52 Tower emhttp: _shcmd: shcmd (30): exit status: 1
Oct 14 17:51:52 Tower emhttp: Retry unmounting user share(s)...
Oct 14 17:51:55 Tower emhttp: disk_temperature: ATTR_Temperature_Celsius not found

 

and this just goes on forever

That is because you have a process holding a file open on one of your user-shares.

 

Or, you started a process with a current directory being one of your user-shares.

 

Or, you logged in and changed directory to one of your user-shares and it is your current working directory.

 

The command built into unMENU will force terminate those types of processes.  The unRAID built in commands will not.  unRAID's stop command will wait until those processes exit on their own. (potentially forever)  Eventually, though the syslog file will fill, and you'll use up all available memory, and your server will begin to kill off processes.. (effectively crashing)

 

Joe L.

That is because you have a process holding a file open on one of your user-shares.

 

Or, you started a process with a current directory being one of your user-shares.

 

Or, you logged in and changed directory to one of your user-shares and it is your current working directory.

 

The command built into unMENU will force terminate those types of processes.  The unRAID built in commands will not.  unRAID's stop command will wait until those processes exit on their own. (potentially forever)  Eventually, though the syslog file will fill, and you'll use up all available memory, and your server will begin to kill off processes.. (effectively crashing)

 

Joe L.

 

That's good to know! Thanks for clearing up that mystery for me.

Ok, solved my own mystery with this one. All of the issues were caused by my inexperience pretty much, but in case someone else experiences similar things, here are the answers...

 

Firstly, the fact that the drives were getting reassigned when I added new ones was due to the fact that I had my disk1 plugged into SATA-6 port (which is the last one). Because of that, it would always get mounted as the last drive. So if it was /dev/sdd1 before adding a new disk, it would become /dev/sde1 after new disk addition. So it seems that unRAID does depend on disks being mounted in the same order between reboots instead of associating their IDs with the respective slots.

 

Secondly, the mysterious Downloads share that was appearing out of nowhere was there because a folder called /mnt/disk1/Downloads/ was always present, even when the array was stopped. The culprit was sabnzbd which was creating it during boot time. So top tip - in the folders section of SABnzbd configuration, use relative paths instead of absolute ones and SABnzbd will not create them. For example, instead of "/mnt/disk1/Downloads" use "../mnt/disk1/Downloads".

 

So there it is, all issues solved! I have rearranged everything and labeled the cables so that I know exactly which slot each one is connected into. That should help in the future. Now I'm off to figuring out why the RAID controller complains when connecting jumpered advanced format drives..... Thanks again for all the helpful pointers!