[unRAID 6 beta14+] Unassigned Devices [former Auto Mount USB]


Recommended Posts

What I did was stop array, manually unmount the disks (on command line) and start the array again.

 

These bugs will be squashed out in the next release. Since I revamped a lot of code, I'll test it more for a day or two.

 

I did it via the gui and it worked fine.  This is a minor issue.

 

Still doesn't explain the unmountable error from the unRaid array for these 2 disks.  I don't know what could cause this.

Link to comment

I'm not sure if this is related to the above discussion, but. I updated my plugins and took my server down for a reboot last night.

 

Came back up again, but some of my dockers were reporting issues getting to the download folder. The download folder live son an external drive mounted via Unassigned Devices. Jump on the server and could see the drive mounted, but as a different assignment. Go into Main and expand out the UAD section and sure enough the drive is mounted in a new location, and the old drive mount is now listed as a missing device. (greyd out at the bottom of the section)

 

I remove the old drive mounting and remount the new drive listing as the old mount point. Restart all the dockers. Still dont work.

Seems they are unable to read/write into the file system.

 

SSH to the server, go into the mount, create some files and folders, all fine. Unmount, remount elsewhere, still works for root. Repoint the dockers, still can't read/write to the FS.

 

So i'm guessing the permissions on the mounts have changed in the most recent version? Not entirely sure what to do atm i relied a bit on this drive to hold all my docker config backups aswell as handling downloads pre import. I've tried setting the owner of the disk to the right users for dockers, no dice, set to 0777, no dice.

 

Has anyone else had this occur?

Link to comment

I'm not sure if this is related to the above discussion, but. I updated my plugins and took my server down for a reboot last night.

 

Came back up again, but some of my dockers were reporting issues getting to the download folder. The download folder live son an external drive mounted via Unassigned Devices. Jump on the server and could see the drive mounted, but as a different assignment. Go into Main and expand out the UAD section and sure enough the drive is mounted in a new location, and the old drive mount is now listed as a missing device. (greyd out at the bottom of the section)

 

I remove the old drive mounting and remount the new drive listing as the old mount point. Restart all the dockers. Still dont work.

Seems they are unable to read/write into the file system.

 

SSH to the server, go into the mount, create some files and folders, all fine. Unmount, remount elsewhere, still works for root. Repoint the dockers, still can't read/write to the FS.

 

So i'm guessing the permissions on the mounts have changed in the most recent version? Not entirely sure what to do atm i relied a bit on this drive to hold all my docker config backups aswell as handling downloads pre import. I've tried setting the owner of the disk to the right users for dockers, no dice, set to 0777, no dice.

 

Has anyone else had this occur?

 

Im experiencing this aswell, except im trying to use "new drives" for this purpose. After investigating i found that files are being written in the chosen path under the disk. e.g.

 

rsync my plex library to ssd, mount it as /mnt/disks/plex, attach to plex container, start the container. I The observe the "welcome to..." wizard, turn off the container, unmount the disk. Then via root@unraid i browse to /mnt/disks/plex and the metadata is still present. (It was written to the underlaying drive rather then the disk i mouted.)

 

feel free to join me on irc if you want help testing this gjar

Link to comment

 

Im experiencing this aswell, except im trying to use "new drives" for this purpose. After investigating i found that files are being written in the chosen path under the disk. e.g.

 

rsync my plex library to ssd, mount it as /mnt/disks/plex, attach to plex container, start the container. I The observe the "welcome to..." wizard, turn off the container, unmount the disk. Then via root@unraid i browse to /mnt/disks/plex and the metadata is still present. (It was written to the underlaying drive rather then the disk i mouted.)

 

feel free to join me on irc if you want help testing this gjar

 

I don't need, since this is expected. unRAID run Docker unsharing the mount namespace. The reason is a bug I really don't understand well, and the major drawback is that any mounts executed after the docker daemon is up will not be propagated though docker containers.

 

The workaround is to define a script restarting docker after a disk mount. You can even define a Common Script, that will execute on every disk mount, under Settings->Unassigned Devices.

 

More info here.

Link to comment

I don't need, since this is expected. unRAID run Docker unsharing the mount namespace. The reason is a bug I really don't understand well, and the major drawback is that any mounts executed after the docker daemon is up will not be propagated though docker containers.

 

The workaround is to define a script restarting docker after a disk mount. You can even define a Common Script, that will execute on every disk mount, under Settings->Unassigned Devices.

 

More info here.

 

I've been restarting the dockers themselves while i was testing the problem. Do you mean the docker service itself needs to be restarted?

 

Sorry the linked doc is a bit beyond my understanding :(

 

I am also unsure why this is a problem only recently. Based on my reading of that doc it seems it should have been a problem all along?

Link to comment

I don't need, since this is expected. unRAID run Docker unsharing the mount namespace. The reason is a bug I really don't understand well, and the major drawback is that any mounts executed after the docker daemon is up will not be propagated though docker containers.

 

The workaround is to define a script restarting docker after a disk mount. You can even define a Common Script, that will execute on every disk mount, under Settings->Unassigned Devices.

 

More info here.

 

I've been restarting the dockers themselves while i was testing the problem. Do you mean the docker service itself needs to be restarted?

 

Sorry the linked doc is a bit beyond my understanding :(

 

I am also unsure why this is a problem only recently. Based on my reading of that doc it seems it should have been a problem all along?

 

1) The Docker daemon needs to be restarted: /etc/rc.d/rc.docker restart

 

2) Maybe because you only had to change the mount path now. Usually, UnDev disks are mounted prior to Docker startup.

Link to comment

1) The Docker daemon needs to be restarted: /etc/rc.d/rc.docker restart

 

2) Maybe because you only had to change the mount path now. Usually, UnDev disks are mounted prior to Docker startup.

 

Thats worked. Guess i'll add something to restart docker a few seconds after.

 

Thanks :)

Link to comment

What I did was stop array, manually unmount the disks (on command line) and start the array again.

 

These bugs will be squashed out in the next release. Since I revamped a lot of code, I'll test it more for a day or two.

 

I did it via the gui and it worked fine.  This is a minor issue.

 

Still doesn't explain the unmountable error from the unRaid array for these 2 disks.  I don't know what could cause this.

 

The major issue is the fact that no-how was I able to mount these disks to the array.  They were formatted XFS with the normal unRaid process on a 2nd server prior to being mounted by UnDev, and rsynced full of data, having all the data verified by bunker hashes, then moved to the unRaid array.  At this point they show as unmountable, which has never before happened.  I've done this for all other disks being converted RFS->XFS.

 

Should I start all over again?  Will another preclear help?

 

Link to comment

Hey Guys,

 

jonp asked me to pass along this information to you this plugin.

http://lime-technology.com/forum/index.php?topic=42919.0 

 

This thread was about some issues I was having with this plugin and its preventing my VM's from working.  I was using the current version of the VM up till the point I uninstalled it.  The basic gist of the issue was that with this plugin installed after between 12 - 20 hours I would get the following error

Execution Error

cannot write data to file '/var/run/libvirt/qemu/openelec.xml.new': No space left on device

 

After a lot of trouble shooting and back and forth, we finally narrowed it down to the plug in.  This issue was occurring with the 6.1.2 version of Unraid.

 

If you need anymore details about it, just give me a shout.

 

Andrew

Link to comment

The major issue is the fact that no-how was I able to mount these disks to the array.  They were formatted XFS with the normal unRaid process on a 2nd server prior to being mounted by UnDev, and rsynced full of data, having all the data verified by bunker hashes, then moved to the unRaid array.  At this point they show as unmountable, which has never before happened.  I've done this for all other disks being converted RFS->XFS.

 

Should I start all over again?  Will another preclear help?

 

I still am investigating and find the following in the log from when I asked UnDev to mount these 2 drives that unRaid sees as unmountable

 

Sep 22 09:02:03 Kim kernel: XFS (sdc1): Mounting V5 Filesystem
Sep 22 09:02:03 Kim kernel: XFS (sdc1): Ending clean mount
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Mounting V5 Filesystem
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Ending clean mount

 

We didn't have XFS on V5 so not sure what this means....

 

Link to comment

 

Sep 22 09:02:03 Kim kernel: XFS (sdc1): Mounting V5 Filesystem
Sep 22 09:02:03 Kim kernel: XFS (sdc1): Ending clean mount
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Mounting V5 Filesystem
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Ending clean mount

 

We didn't have XFS on V5 so not sure what this means....

That's referencing version 5 of the XFS file system, not the unraid version.
Link to comment

I still am investigating and find the following in the log from when I asked UnDev to mount these 2 drives that unRaid sees as unmountable

 

Sep 22 09:02:03 Kim kernel: XFS (sdc1): Mounting V5 Filesystem
Sep 22 09:02:03 Kim kernel: XFS (sdc1): Ending clean mount
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Mounting V5 Filesystem
Sep 22 09:02:44 Kim kernel: XFS (sdg1): Ending clean mount

 

We didn't have XFS on V5 so not sure what this means....

 

This only means that the drive has being mounted successfully.

Link to comment

Hey Guys,

 

jonp asked me to pass along this information to you this plugin.

http://lime-technology.com/forum/index.php?topic=42919.0 

 

This thread was about some issues I was having with this plugin and its preventing my VM's from working.  I was using the current version of the VM up till the point I uninstalled it.  The basic gist of the issue was that with this plugin installed after between 12 - 20 hours I would get the following error

Execution Error

cannot write data to file '/var/run/libvirt/qemu/openelec.xml.new': No space left on device

 

After a lot of trouble shooting and back and forth, we finally narrowed it down to the plug in.  This issue was occurring with the 6.1.2 version of Unraid.

 

If you need anymore details about it, just give me a shout.

 

Andrew

 

I highly doubt it has anything to do with UnDev, but if you reinstall it any day and the bug manifest again, please send me a log file, so I can debug this.

 

Thanks for reporting.

Link to comment

Hi Everyone,

 

I am using UnassignedDevices to link to disks on a separate UnRaid system - so I can move files from one UnRaid to the other.

 

Because it is a more powerful computer, I am using UnassignedDevices on my "Destination" computer - and then using Midnight Commander to connect to the "Source" computer and move files.  When I do this, the files get Copied fine, but when MC goes back to delete them on the "Source" computer it errors with "Permission denied (13)".

 

Is there a way to fix this?  (Other than to load UnassignedDevices on the "Source" computer to do the move)

 

Thanks,

 

Russell

Link to comment

Hi Everyone,

 

I am using UnassignedDevices to link to disks on a separate UnRaid system - so I can move files from one UnRaid to the other.

 

Because it is a more powerful computer, I am using UnassignedDevices on my "Destination" computer - and then using Midnight Commander to connect to the "Source" computer and move files.  When I do this, the files get Copied fine, but when MC goes back to delete them it errors with "Permission denied (13)".

 

Is there a way to fix this?  (Other than to load UnassignedDevices on the "Source" computer to do the move)

 

Thanks,

 

Russell

 

You are using SMB? You can try to use NFS instead.

Link to comment

Hi gfjardim,

 

I have two UnRaids.  Currently I'm using disk shares and had to create a user account through the GUI to do the transfers (not sure why, but root didn't work).

 

I have used this command to make the shares and move data:

 

mount -t cifs -o sec=ntlm,user=filemove,password=mypassword //tower2/tv /mnt/tower2_tv

 

But Squid suggested this plugin might be an easier way (http://lime-technology.com/forum/index.php?topic=13432.msg408894#msg408894)

 

I don't know linux at all - so I love GUI stuff.  :-)  I haven't found a place where I can control permissions of shares - my family doesn't access Unraid directly, so I've never had the need to look.

 

Thanks,

 

Russell

Link to comment
  • Squid locked this topic
Guest
This topic is now closed to further replies.