Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array


dlandon

5538 posts in this topic Last Reply

Recommended Posts

On 6/3/2020 at 6:06 PM, dlandon said:

You didn't get it quite right.  Delete /flash/config/plugins.unassigned.devices/*.cfg, then immediately reboot.  There are working copies in memory that will overwrite the ones on the flash unless you reboot right away.

Thank you for getting back to me!

 

I just tried this in the order you wrote it and the errors are still there after the reboot :(

Link to post
  • Replies 5.5k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

New release of UD.  Changes: When changing the mount point (which is also the share name), the mount point is checked for a duplicate of a user share or another UD device.  Samba cannot handle

While I appreciate your interest in esthetics, there is more to consider than just 'aligning' disk drive mounts: This disk is mounted without a UD script, it is probably better to put it in th

<step on soap box> Keep in mind that the Unraid array disk configuration is static and doesn't change until it is stopped.  UD has to deal with hot plugged disks, devices being dynamically

Posted Images

1 hour ago, Solverz said:

Thank you for getting back to me!

 

I just tried this in the order you wrote it and the errors are still there after the reboot :(

You probably have a corrupted flash drive.

Link to post
19 minutes ago, dlandon said:

You probably have a corrupted flash drive.

Just did some more testing. This only happens with the nvidia unraid build as when using stock unraid, I get no errors at all!

 

Have you heard of this issue before?

Link to post
5 minutes ago, Solverz said:

Just did some more testing. This only happens with the nvidia unraid build as when using stock unraid, I get no errors at all!

 

Have you heard of this issue before?

No.

Link to post
4 minutes ago, dlandon said:

No.

I see, thank you for the help by the way I appreciate it :)

 

Would you think this issue is being caused by an issue with the unraid build or unassigned devices itself? or any ideas on what I could do to figure out what is going on? :)

 

Link to post
1 hour ago, Solverz said:

I see, thank you for the help by the way I appreciate it :)

 

Would you think this issue is being caused by an issue with the unraid build or unassigned devices itself? or any ideas on what I could do to figure out what is going on? :)

 

Let me set it up on my test server and see if I can figure it out.

Link to post
1 minute ago, dlandon said:

I just fired up Nvidia 6.8.3 and don't see any problems.

Thank you for testing that, I just found some important information to add below as soon as your post came through!

 

I just done some more testing and I found out that the issue only occurs when the jellyfin docker has auto start enabled. This happens on the stock and the nvidia unraid build. (I was incorrect in saying it was the unraid nvidia build causing the issue before Sorry!)

 

So to explain what happens: if the jellyfin docker has auto-start enabled and I reboot the server I get the errors (on stock and nvidia unraid). If i disable autostart on the jellyfin docker and reboot the server I get no errors at all.

 

So basically I have no idea why enabling autostart on the jellyfin docker causes this, I tested all my other dockers which includes plex and I get no errors when autostart is enabled on them...

Edited by Solverz
Spelling Correction
Link to post
Just now, Solverz said:

Thank you for testing that I juat found some important information to add below as soon as your post came through!

 

I just done some more testing and I found out that the issue only occurs when the jellyfin docker has auto start enabled. This happens on the stock and the nvidia unraid build. (I was incorrect in saying it was the unraid nvidia build causing the issue before Sorry!)

 

So to explain what happens: if the jellyfin docker has auto-start enabled and I reboot the server I get the errors (on stock and nvidia unraid). If i disable autostart on the jellyfin docker and reboot the server I get no errors at all.

 

So basically I have no idea why enabling autostart on the jellyfin docker causes this, I tested all my other dockers which includes plex and I get no errors when autostart is enabled on them...

I suspect you have a mis-configured docker.  Check your mappings, especially to UD devices.  If you are passing through a UD device to the docker, be sure to mark it 'Pass Thru' in UD so it does not get mounted.  A disk passed through to a docker and mounted with UD will be corrupted.

Link to post
33 minutes ago, dlandon said:

I suspect you have a mis-configured docker.  Check your mappings, especially to UD devices.  If you are passing through a UD device to the docker, be sure to mark it 'Pass Thru' in UD so it does not get mounted.  A disk passed through to a docker and mounted with UD will be corrupted.

I do not have any UD devices being passed through to any dockers but your mention of mappings got me thinking, so I checked them all and decided to re create the Jellyfin docker step by step identically until I ran into the issue. I found out that mapping the dockers transcode folder to /tmp on the host was causing the issue! So after removing this mapping the UD error was no more even with auto start enabled on the Jellyfin Docker.

 

So now the question is why would this mapping cause this error :D

Edited by Solverz
Link to post
3 minutes ago, Solverz said:

I do not have any UD devices being passed through to any dockers but your mention of mappings got me thinking, so I checked them all and decided to re create the Jellyfin docker step by step identically until I ran into the issue. I found out that mapping the dockers transcode folder to /tmp on the host was causing the issue! So after removing this mapping the UD error was no more even with auto start enabled on the Jellyfin Docker.

 

So now the question is why would this mapping cause this error :D

UD keeps working copies of it's configuration files in the /tmp file system and copies changes to the flash to cut down on flash reads and improve response time.  Your docker probably interferred with the /tmp file system.  I'm surpised you didn't have other issues.

Link to post
3 minutes ago, dlandon said:

UD keeps working copies of it's configuration files in the /tmp file system and copies changes to the flash to cut down on flash reads and improve response time.  Your docker probably interferred with the /tmp file system.  I'm surpised you didn't have other issues.

That makes sense, the only reason I mapped it to /tmp is because it is a temp directory in the memory which seems a perfect place for on the fly transcodes and I read everyone else was doing it so thought it was fine to do so but this shows that it is not a good idea.

 

I do not fully understand how it all fundamentally works but I will try and map it to a sub folder in /tmp to see if that makes a difference as I assume it wont interfere with any of the other stuff that is loaded in the root /tmp that way? I could be wrong about this though. :)

 

Thank you for the help again!!!

Link to post
5 minutes ago, Solverz said:

That makes sense, the only reason I mapped it to /tmp is because it is a temp directory in the memory which seems a perfect place for on the fly transcodes and I read everyone else was doing it so thought it was fine to do so but this shows that it is not a good idea.

 

I do not fully understand how it all fundamentally works but I will try and map it to a sub folder in /tmp to see if that makes a difference as I assume it wont interfere with any of the other stuff that is loaded in the root /tmp that way? I could be wrong about this though. :)

 

Thank you for the help again!!!

I agree. I would use a sub-folder and not map to /tmp.  The docker may change permissions and mess up other folders.

Link to post
2 hours ago, itskamel said:

I noticed that every once in a while I get a error in my log. Anyone know what this means? And or should I be concerned?

 

I do have my dockers and VM's running on the NVME samsung drive.

 

firefox_2020-06-19_19-55-51.png.e8ea562ee5b484d3a9818545bf13f347.png

Post your diagnostics.

Link to post
51 minutes ago, itskamel said:

The server hosting your remote shares is going off-line:

Jun 19 09:54:12 Tower unassigned.devices: SMB/NFS server '192.168.1.13' is not responding to a ping and appears to be offline.

This can cause issues with other UD device commands timing out.

Link to post
28 minutes ago, dlandon said:

The server hosting your remote shares is going off-line:


Jun 19 09:54:12 Tower unassigned.devices: SMB/NFS server '192.168.1.13' is not responding to a ping and appears to be offline.

This can cause issues with other UD device commands timing out.

ok that makes sense, so i only have it set to rsync once daily when that machine is on. i wonder why it is trying at 9am? should be doing it at 6am only. also that is from a workstation PC to the array. should have nothing to do with "unassigned drives".

Link to post
7 minutes ago, itskamel said:

ok that makes sense, so i only have it set to rsync once daily when that machine is on. i wonder why it is trying at 9am? should be doing it at 6am only. also that is from a workstation PC to the array. should have nothing to do with "unassigned drives".

If you have CIFS mounts (remote mounts) mounted and the remote server goes off-line, there are Linux commands that will hang even when not done on the CIFS mounts.  That is why UD has timeouts on all commands.  If there weren't time outs, UD would hang.  If I remember correctly the worst are 'lsof' and 'df'.

 

If the remote server is only on at certain times of the day, you shoud unmount the remote shares while it is off.

Link to post

I released a new version 2020.06.20 that fully supports 6.9 Multi Language.  Those of you on 6.9 Beta will be able to download the language packs and have UD translation installed as it gets translated for each language.  @ich777 is working on the German translation.

  • Like 2
  • Thanks 1
Link to post
1 hour ago, dlandon said:

If you have CIFS mounts (remote mounts) mounted and the remote server goes off-line, there are Linux commands that will hang even when not done on the CIFS mounts.  That is why UD has timeouts on all commands.  If there weren't time outs, UD would hang.  If I remember correctly the worst are 'lsof' and 'df'.

 

If the remote server is only on at certain times of the day, you shoud unmount the remote shares while it is off.

ok makes sense now. so should i make a script where it will mount the drive, rsync, then unmount the drive and see how that goes? btw thanks for the reply.

 

Link to post
37 minutes ago, itskamel said:

ok makes sense now. so should i make a script where it will mount the drive, rsync, then unmount the drive and see how that goes? btw thanks for the reply.

 

Yes.

Link to post
On 6/20/2020 at 12:28 AM, dlandon said:

I agree. I would use a sub-folder and not map to /tmp.  The docker may change permissions and mess up other folders.

Mapping to a sub folder worked!

 

Thank you so much for all the help!!! :D

 

EDIT: After testing for a while, mapping to a sub folder in /tmp also started to cause issues.... So based on this I do not think it is a good idea to map to /tmp in any way :(

Edited by Solverz
Correction on findings
Link to post
5 hours ago, Solverz said:

Mapping to a sub folder worked!

You can also use /dev/shm to map to RAM.

/tmp seems to be mounted to rootfs on unRAID and not a tempfs like /dev/shm.  

For unRAID this shouldn't make much of a difference (since it runs in RAM anyways) but for other Linux distros /tmp might not be in RAM while /dev/shm (if available) should always map to RAM-

 

Edited by Thx And Bye
Link to post
1 hour ago, Thx And Bye said:

You can also use /dev/shm to map to RAM.

/tmp seems to be mounted to rootfs on unRAID and not a tempfs like /dev/shm.  

For unRAID this shouldn't make much of a difference (since it runs in RAM anyways) but for other Linux distros /tmp might not be in RAM while /dev/shm (if available) should always map to RAM-

 

Thank you for this helpful information! I will give this a try :)

 

However, mapping to /tmp or /tmp/example/ also started to cause issues, so I have edited my previous post...

 

Anyway, I am going to stop discussing this here as it is going to get off the topic of this UD thread :)

 

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.