dlandon

Ok. So it did mount with the 'sec=ntlm' parameter?

It appears to be a security issue. Go to a command line and try this command: mount -t cifs -o rw,nounix,iocharset=utf8,_netdev,file_mode=0777,dir_mode=0777,sec=ntlm,username=guest,password=******* '//daisy/Movies' '/mnt/disks/daisy_Movies' Change the credentials to your actual credentials. UD changes the password to '*'s to hide the password in the log. Let me know if it mounts the smb share. I added 'sec=ntlm' that is an older security mode for the credentials and used to be the default. The new default is 'sec=ntlmssp' and your NAS is probably using the older method. EDIT: The test I asked you to do is not as straight forward as I thought. I will release a new version of UD today that will try to remount the device with the 'sec=ntlm' if the mount with the default fails. Update UD and then try your mount again and post the UD log entries if it fails.

After some more testing I found that having a hard drive mounted caused the hang up even with 29a. If all you had mounted was the remote share, then my first implementation would work fine. If you would have had a hard drive mounted, it would have hung up also. I'm not really too impressed with the way 'df' works. If i do a 'df' at the command line when a remote mount is offline, df hangs. I would expect it to skip showing the parameters for the offline device or time out after a short time. I had to do the df by device, rather than all devices and 'grep' for the information I needed. This is not scientific, but it appears UD might just be a bit more responsive because of this change also.

You are out of log space. Look at the dashboard page below the cpu load. You'll see stats on the log size being used. You might look at the syslog and see if it is full of messages. Them reboot and try again to install UD. Check your syslog and see if it is filling with messages.

I doubt it. What does the log show?

Upper right hand area of the UD page. Just under the syslog button.

No. That has nothing to do with it.

It needs to mount for plex to see it. Look at the UD log and it will tell you why it didn't mount. I suspect you didn't set the Credentials for the remote smb share.

To start with you need to mount it. Then click on the mount point and you should be able to browse it.

Can you browse the smb share through UD?

As is usual with software, the fix was easy once I understood the problem. It took a bit to isolate the issue. Shouldn't be any negative effects.

The latest version has smb and nfs indicators next to the 'Share' text in the device header to show the share setting in the Settings->Unassigned Devices for the smb and nfs shares. Hopefully this will help people know whether or not setting the share switch will actually share anything and the share protocol being used.

It was more involved than I thought. It is related to doing a 'df' to get the size of the mounted device. Doing a 'df' will hang if a device is offline. I had to do 'df /dev/sdX', etc. I only partially solved it in 29a. I will be releasing a 29b today. EDIT: 207.01.29b is available.

It looks like UD is trying to calculate size and used/free space on a disconnected SMB or NFS share and probably taking a long time to fail out. I added a check to see if the mount has disconnected and bypassing these calculations if it is. I have a release ready to go today and I'll include this fix. Let me know if it helps.

Can you post a UD log when this happens? Click on 'Help' and you'll see a 'Download' button at the bottom of the help to download the log.

That would involve work by bonienl to include the UD disks in the disk stats plugin. You'll need to lobby him to see if he is interested, feels it adds value, and if he has the time.

Not when using Slave mode for access (and the mount point is within /mnt/disks) I'm sure this is all user error somewhere in what @DW_Michi is doing @DW_Michi: From the Docker Tab, next to plex, it should show /hello -> /mnt/disks/192.168.... When you click on that does it show you the contents of the remote mounted share? I think he solved it. Probably the spaces issue and not having to re-start docker.

I don't understand fully why that is necessary, but that's why I put the notice in the mount dialog.

It looks like there is a space between the /mnt/disks/ and the ip address. This would be a problem.

You have to enable the share setting for SMB and/or NFS or UD will not share. You have not set enable 'Yes' in UD settings. Do you require that? We're not trying to access it via SMB or NFS. Merely get at the UD mounted share within a container The topic is mounting SMB shared into a plex docker, so I'm confused as to what the problem is. If a remote NFS share is mounted with UD and not shared (either with SMB or NFS) it will be mounted at /mnt/disks/share name. I would think the docker would be able to access it at the mount point. Remember that there is an issue with a docker seeing a UD mounted share unless docker is restarted after the UD mount. I also recommend using the server name and not the ip address to reference it. When setting up a NFS mount, enter the NFS server name and then click the 'Load Shares' to get a list of the shares and then make a selection. If the shares don't show up, there is a problem on the hosting server that prevents UD from seeing the shares.

You have to enable the share setting for SMB and/or NFS or UD will not share. You have not set enable 'Yes' in UD settings.

Go to the UD Settings and be sure you are sharing the UD devices with the proper permissions.

UD can sometimes have trouble finding shares depending on the master browser on the network. I recommend setting unRAID as the master browser in the SMB Settings so UD has a better chance of finding shares on the network. If you set up vlans on unRAID you must set it as the master browser or you will have problems on the vlans finding servers and shares.

I updated to the latest version and the 'Preview' (eye) function does not show the status and the log shows: Jan 27 16:48:26 BackupServer root: error: plugins/preclear.disk/Preclear.php: missing csrf_token Jan 27 16:48:27 BackupServer root: error: plugins/preclear.disk/Preclear.php: missing csrf_token Jan 27 16:48:28 BackupServer root: error: plugins/preclear.disk/Preclear.php: missing csrf_token EDIT: 6.3.0-rc9.

You are not doing it correctly. Vcpus are numbered from '0'. Vcpus are the VMs CPUS and not the system cpus. You are also only assigning one of the thread pairs. This results in too much context switching. You are better off assigning thread pairs to a VM. Don't edit the xml and assign cpus. Use the VM editor. Once you do that, then add the emulatorpin if necessary. I think you want to do this: <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='14'/> <vcpupin vcpu='4' cpuset='15'/> <vcpupin vcpu='5' cpuset='16'/> <emulatorpin cpuset='0-12'/> </cputune> So with the VM editor assign 2,3,4,14,15,16 cpus and let the VM editor make the settings. You only need to emulatorpin a thread pair. That's generally enough. This setup assigns 3 cores and 6 threads to your VM. I doubt you need any more cpus. Re-read the first post and be sure you understand cores and threads.