dlandon

New UD release features: Changing the mount point will now change the physical disk label on ntfs, btrfs, xfs, vfat, btrfs encrypted, and xfs encrypted disks. There is a new switch in the upper right corner of the UD page ('None' and 'All') that will show all partitions on all disks when switched on. This is a UD setting and not a cookie, so it will be persistent. Thanks @Lev and @TexasUnraid for your ideas.

The command to put a drive in standby should not cause a SSD disk to stop working, but I've seen this before. I have several Samsung SSDs and have never had the issue myself.

Check your disk cabling and connections.

I've seen your request and I'm pondering a possible solution.

Not difficult, just had to find all the different commands for each file system type. There are a few limitations - ntfs label is limited to 32 characters, vfat is upper case only and limited to 11 characters. Not sure of the limits on xfs and btrfs file systems.

I've implemented changing the physical disk volume label on xfs, btrfs, vfat, ntfs, and encrypted disks when the mountpoint is changed.

Looks like I might be able to do ntfs, xfs, and btrfs. I'm looking into it.

What format partitions are you wanting to label? Linux choices are fairly limited.

Click on the partition name and change it. Hover your mouse over the partition name for details.

What do you mean by partition name?

Go to a terminal session and do 'ls /mnt/disks/(mountpoint)' and see what is contained in the folder. That will help you track down what is happening.

Find it in the Historical Devices and delete the configuration.

If it is showing up in UD, you haven't assigned it to the array.

Dockers are presented to CA so they are available to users. CA doesn't have anything to do with the installation instructions of Dockers. That is up to the individual Docker contributors. Most of the time there are instructions and comments in the first post of that particular Docker forum. Users are expeced to read the first post for details on the use of the Docker. In the case of this Docker, there is one mapping change and the user name and passwords need to be chosen by the user. It is bad practice to use a default user name and passwords that a user would never change. I don't see that as particularly difficult. This Docker also needs a lot of customization for your particular situation. Sorry if you feel the installation of this Docker is not appropriate, but I don't intend to make any changes. Yes, I am the contributor of this Docker.

UD does not change anything from 'stock'. It is only a way to manage unassigned disks. All the UD settings apply only to UD. Correct. Linux will mount the disk as read only. The reason UD does not do this is that it interrupts SMB trasfers. UD does a Samba refresh. If you are copying a file and restart Samba, you will probaby cause a failure in the fie transfer. I would recommend you don't do this. Just wait for a bit and the share will show up.

I've been converting several of my plugins following the rule book with great success. The design is pretty much finalized and @bonienl has a design guide that I've been using that is up to date. It will be up the to plug in authors to add the multi language feature to their plugins.

Minor display issue on Wireguard:

The defaults are set by ownCloud in their package. This is very common. If it doesn't work for you, feel free to find another docker that will meet your needs.

No. They are not the default settings. OwnCloud is used in many different settings and they are set for each particular situation by the user.

Yes.

I mis-read the screen shot. You have those two disks marked as "Pass Thru". Temperatures don't show when a disk is passed through. The only thing shown is the file system and disk size.

I see that.

Normally those are partitions on the same drive and temperatures would be redundant. This is not a typical UD disk setup.

Working for a lot of other people. Be sure to follow the instructions on the first post. Change the data folder to /data. Because the database is built into the container, the database host is localhost. The database user and the database itself are both 'owncloud'.

It looks like a cable issue.