dlandon

@NAS This discussion all began with you saying that USB disks would make a noise when spun down. I asked you to do some testing for me: Can you please respond to this post and let me know if it makes a difference?

Be sure it has execute permission: 'chmod +x occ'. To execute it: 'sudo -u abc ./occ'.

I just loaded a fresh version of ownCloud on my test server starting from scratch, and it seems the initial download link of ownCloud has been changed so the download of ownCloud failed. I have fixed this in the docker container. Update the ownCloud docker and it should work now.

This is some of samba’s strangeness. I’d say the 2.002 is a bug in the printer (typo) and it should be 2.02.

Use the remote share if it is a smb share.

You should set up the SSD disk as a Pool device and don't put it in the array. SSD trim does happen on an array disk and you'll suffer speed degradation over time. Set it up as a Pool device. All of ownCloud appdata/ will have to be on one disk. You can't have appdata/ and /data on separate disks. Partly, but I think the real reason is your mapping of appdata/. As I said, /data has to be appdata/data. On the start up dialog set data to /data. That's only a suggestion. No it's not causing the error.

Probably, but I've never done that. That won't work. The data can only be set to /data as it becomes a folder in ownCloud - /appdata/ownCloud/data/. You can't put the data somewhere else. I wouldn't use a user share for ownCloud. It's better in a Pool device. If it's on the array, disks will not be able to spin down because of all the activity. Where is your appdata share mapped?

It doesn't look like you are mapping the folders properly. Emby is set to use /mnt/ and you map the media folders in the docker itself: Once inside Emby, you select the folders for the media you want to use: and choose the folders for each media type: or probably the best approach: Substitute your server name for 'Tower'.

If you look at the failure of starting the docker, it is because Emby is trying to create the directory 'mkdir /mnt/remotes/DATENLAGER_filme/' and it fails because that mount point exists. It was already created by UD. I'm not understanding why a docker is trying to make a directory that should already exist and should be used to access existing media.

I would stay with the default configuration of ownCloud Redis. Redis is very touchy and may cause more trouble than it is worth. As for the database, you can use a seperate database by configuring it when you do the first setup of ownCloud.

What docker are you using from CA? I'd like to give it a try.

The correct path for your remote share is /mnt/remotes/DATENLAGER_filme/. The issue seems to be with the Emby Docker trying to mkdir on /mnt/remotes/DATENLAGER_filme/. Emby is tyrying to create that mount path. Emby should only be using that path for gathering media. Post a diagnostics file.

I've done a bit of research into this along with several other people here on the forum. The conclusion is that this isn't anything LT will be interested in working on for the following reasons: You are using a printer that needs a firmware update. SMB is not written by LT. LT configures samba, but has no control over it's operation. You appear to be the only user experiencing this issue. You have several options here: Enable SMBv1 and live with that. Lobby your printer manufacturer to provide a firmware update. Take your issue to the samba development team for a resolution. A future release of samba may resolve this issue, but I doubt it.

Do the following: Remove all the docker containers. Delete all the appdata container folders. Re-install docker containers again. Do not run the "New Permissions" the appdata folder permissions are controlled by the docker containers and running "New Permissions" will create issues with the container permissions. The docker containers will handle the permissions.

Click on the 'force update' text.

Switch to the Advanced View on the dockers page, then click 'force update'. The container may have an issue and this will start with a fresh container.

You need to look at the app you're using. It seems to be a permissions issue.

Can you browse the share and see the files with a PC?

Post diagnostics file. How are you referring to the disk device with Autolt3?

Correct.

Unraid does not use fstab. This is the exports file from my test server: root@BackupServer:~# cat /etc/exports # See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. "/mnt/user/AV Media" -fsid=106,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) "/mnt/user/Computer Backups" -fsid=103,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) "/mnt/user/Public" -fsid=107,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) "/mnt/user/isos" -fsid=105,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) root@BackupServer:~# Looks to me to be /mnt/user/sharename. This is UD mounting a NFS share on my Unraid test machine: Sep 6 15:55:42 BackupServer unassigned.devices: Mounting Remote Share 'BACKUPSERVER:/mnt/user/Public'... Sep 6 15:55:42 BackupServer unassigned.devices: Mount NFS command: /sbin/mount -t 'nfs4' -o rw,noacl 'BACKUPSERVER:/mnt/user/Public' '/mnt/remotes/BACKUPSERVER_Public' Sep 6 15:55:42 BackupServer kernel: Key type dns_resolver registered Sep 6 15:55:42 BackupServer kernel: NFS: Registering the id_resolver key type Sep 6 15:55:42 BackupServer kernel: Key type id_resolver registered Sep 6 15:55:42 BackupServer kernel: Key type id_legacy registered Sep 6 15:55:42 BackupServer rpc.mountd[5560]: v4.0 client attached: 0x89ca572963161e48 from "127.0.0.1:856" Sep 6 15:55:42 BackupServer nfsrahead[12889]: setting /mnt/remotes/BACKUPSERVER_Public readahead to 128 Sep 6 15:55:43 BackupServer unassigned.devices: Successfully mounted 'BACKUPSERVER:/mnt/user/Public' on '/mnt/remotes/BACKUPSERVER_Public'. Sep 6 15:55:43 BackupServer unassigned.devices: Adding SMB share 'BACKUPSERVER_Public'. Sep 6 15:56:42 BackupServer unassigned.devices: Removing Remote SMB/NFS share 'BACKUPSERVER:/mnt/user/Public'... Sep 6 15:56:42 BackupServer unassigned.devices: Unmounting Remote SMB/NFS Share 'BACKUPSERVER:/mnt/user/Public'... Sep 6 15:56:42 BackupServer unassigned.devices: Synching file system on '/mnt/remotes/BACKUPSERVER_Public'. Sep 6 15:56:42 BackupServer unassigned.devices: Unmount cmd: /sbin/umount -l 'BACKUPSERVER:/mnt/user/Public' 2>&1 Sep 6 15:56:42 BackupServer unassigned.devices: Successfully unmounted 'Public' Sep 6 15:56:42 BackupServer unassigned.devices: Removing SMB share 'BACKUPSERVER_Public'

I'll try the best I can to begin to answer some of the issues raised here. I'm not an expert on NFS, but I'll do what I can to get answers. I think there is some confusion here about the NFSv4 volatile file handles. I don't understand the comments about pseudofilesystem. The stale handles in NFSv3 occurred on Unraid mainly when files were moved by the mover. Moving the files to another location (that's what the mover does) would make the old file handle reference to the file 'stale'. There were many hacks tried to overcome the file handles - none of the attempts were all that succesfull. The volatile file handles feature of NFSv4 takes care the stale file handles much better. As far as I know there is no conversion required. NFSv4 works the same as NFSv3 on Unraid. Those of you with permissions issues, please post diagnostics when you have those issues and we can see if we can find the answers you need.

This command is not available in Unraid and I'm not keen on adding it. If I implement a 'safely_remove' feature it will not be generic in the sense that it will not be done on every unmount. The user will have to add a 'safely_remove' command, and only USB devices will be operated on. You can appreciate doing a safe removal on a built in hard disk by accident. A reboot would be required to restore it. I'm not sure a re-attach is practical for UD. Once a disk device is safely removed, it becomes a historical device and UD would have to track the device bus address and store it on the flash device. Over the years, LT has stressed the need to reduce/eliminate flash writes. The reattach idea, while seemingly a cool thing, is probably not a main stream need and removing and re-installing a USB device is not that much of an inconvenience for the few times it might be needed. Also, if you think you might want to re-attach the drive without removing it first, don't do a safe removal command. There is also the concept of auto mount. The UD script would be run again and this might not be the desired action on a reattach. This is the way I'm thinking about a 'safely_remove' command: 'REMOVE' ) # do your stuff here # Spin down disk - uncomment this if you want the disk to be spun down after the disk is unmounted # /usr/local/sbin/rc.unassigned spindown $DEVICE # Safely remove the disk - uncomment this if you want the disk to be detached after the disk is unmounted # /usr/local/sbin/rc.unassigned safely_remove $DEVICE /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Unassigned Devices" -d "Device unmounted" -i "normal" ;; I've changed the spindown command to now use the /dev/sdX device designation as well as the alias so it can be used in the UD script without having to assign an alias to the device. The same applies to the 'safely_remove' command. You don't need a disk alias for the command to work.

It's nothing you are doing wrong. Windows server disks are partitioned in a way that Linux does recognize the file system. If you can attach the disk to a computer and mount it, you can connect to it using a UD remote share to get at your data. If you want it to be readable by UD, you'll need to remove the data and reformat it using UD.

What is the situation here? Safe mode with UD and UD preclear plugins only installed?