dlandon

Try this: Update to the latest UD. There have been some fixes lately for this issue. If that doesn't work, post your diagnostics The devX designations will change and are not fixed to a serial number. No. All that will do is remove the settings and not fix this issue at all.

It's really simple and does not require a constant background check. When UD is asked to mount the remote share it checks to see if the server is online from the ping status from the last run of background script. In your case it found the remote server was last found offline and issued the log message. Now what I'm doing is running the ping status update when the server is found offline, and then check again if it is online. The ping background check is very fast and won't slow down the mount. Good news is that the ping status script won't be run unless needed to refresh an offline server status. The reason for the remote server online check is a mount will fail if it the remote server is offline. It will be fixed in the next release.

I think the issue is that UD doesn't have the current ping status when you execute the mount. UD runs a background task that keeps up the remote server status. This only runs when the UD page is running. The last status may or may not be up to date and show the correct ping status. What will probably have to happen is that the ping status will have to be updated before UD tries the mount. Let me look at a fix.

This is happening because the Synology is off line. At least at the time you are trying to mount the remote share. In your script you need to set up a check that the Synology can be pinged successfully before you start your script.

Go to a command line and verify the mount point: ls /mnt/disks/ The mount point is the text next the the three icons under the serial number on the UD page. Make sure you don't have a typo. It's case sensitive.

I've found a few problems with the way UD creates a default mount point and released an update. You could try upgrading UD and see if this might straighten out your issue.

I guess I felt the need to butt in. Sorry.

I have found some issues with the default mount point that UD comes up with. Not exactly sure why it has changed lately, but probably because several unassigned variables were being used and this can cause unpredictable results. I've made some changes for the next release.

Something changed in UD that changed the default mount point. Unless the user manually sets the mount point to commit it to the UD device configuration, it could change again. I don't recommend using the default mount point because it defaults to a very cryptic value. A user should set a verbal mount point that makes sense about the function of the device. I think this might come from users not knowing that the mount point can be set to any value they want and the default is not really a good choice.

It appears you installed the disk and let UD assign a default mount point. Something has changed in UD lately (not sure what I did to cause this), but the default mount point has changed. Unless you change the mount point manually, UD will not keep a permanent mount point in the configuration file for that drive. It could change again. At this point you can set the mount point to the one the docker container is expecting and it should start. Click on the mount point when the UD device is unmounted and set the correct mount point.

This is a bug in UD that I haven't fixed yet. UD was first implemented many years ago before I took it over. It was originally done as a way to install a USB device and do a quick copy from/to the device. Unfortunately, the way it was implemented and has been changed over the years, it has broken the ability to click on the table header. I have it as a bug fix in UD tasks, but I suspect it will take some rewrite to make it work. It's not a high priority right now. Clicking on the table header is one way to enable the help, but there are others. Press the F1 key, or click the help icon in the upper right of the page to toggle the help. In the non-tabbed view this is really messy because the help is enabled on all pages and you'll have to scroll through all the help to get to UD.

Don't hear that very often.

As you mentioned, the only way is to exclude the shares you don't want. How many do you have? Are they long names? Let me see how long the exclude line is. I may be able to increase the size.

Samba has changed some things. Files are now deleted and put in a folder with the same name as the file. As far as I know, I can't change that behavour.

Several points: You are aware that the recycle bin only shows files deleted from SMB shares? Using mover or deleting then from a command line won't show them in the recyce bin. The .Recycle.Bin folder is a hidden file in SMB shares unless you've turned off 'Hide "dot" files:' in Settings->SMB. It can take up to several minutes for the Recycle Bin page to actually show deleted files in your shares because of the background update. The physical .Recycle.Bin folder will be in your share immediately. Zero length files are not put in the recycle bin. Empty folders aren't save in the recycle bin. I think you're trying too hard and need to have a little patience to let the recycle bin to work,

This is what I'm looking at:

Getting the source of the device is not an issue. There is very limited real estate on the main UD page to display it though, so I'll probably have to put it in the device settings. A simple click of the thee gears would get you there. It'll be in the next release. It is best to post in the UD thread so I will be sure to get a notification of your request. I don't always see these other posts. Luckily @Squid pointed it out to me.

I don't use the non-tabbed view so I've never seen this before. I'm looking into it.

You will need to post your diagnostics zip file so I can have a look.

I think it's more related to incorporation into the WebUI. We'll get back once we are ready. Please don't view this response as we are not interested in your issue. I think it's a good idea. The problem right now is Limetech is undergoing some serious growth and we are working behind the scenes to get more organized and responsive to requests like yours.

If you wanted to pursue this further, the best way is for me to team viewer to your system. Your choice.

Upgrade to 6.10rc2 and use NFSv4.

That would be a good idea. Honestly I am at a loss, Linux thinks the drive is mounted, but by all indications, it's not. Before you do that, remove the disklocation-master plugin. And try again,

Has this just started to be a problem, or has it always been a problem? Try one more command for me: mount | grep /dev/sdk

Something is mounting /dev/sdk. Let me look at the diagnostics once more.