[email protected]

Latest knex66 Nextcloud build as of today, on UNRAID 6.12.3 Seem to have the dreaded 'Error when assembling chunks, status code 504" error when i upload large files. The files do actually get uploaded if you leave it alone for 10 mins... This server is behind an HA proxy for its main use, however if i upload a large file from another machine direct to the Nexcloud instance (ie http) the problem still occurs, so not proxy related. I have added: php_value upload_max_filesize 16G php_value post_max_size 16G php_value max_input_time 3600 php_value max_execution_time 3600 to the .user.ini as suggested in the Nextcloud docs, but to no avail. Is there anything else `I should be doing?

Seems there was a network issue that was breaking the connection to the 2019 server... some asymetric routing causing chaos..... odd it worked before though, and if done manually still did... The second connection to the 2016 server went away when i upgraded that server to 2019 (some what overdue!!). So all up and running now. Thanks for your support.

I have a strange problem that i cannot get fix. Since the recent Unassigned devices updates, i can no longer attach to any windows shares in my estate. Initially i had the issue with attaching to $shares but the updates have fixed that. I have simplified to connections for testing, One is to a share in a Windows Server 2019 server, and the other to a share on a windows 2016 server. Neither will work when i try to connect with UD. They both fail with logon failure, and are also reported in Windows logs a logon failures. If i do a manual connect from the unraid server copying the UD line (from syslog) and substitute the credentials file reference for username and password. The connection works (clearly i have to manually create the mount point first. ie: sudo /sbin/mount -t 'cifs' -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,username='xxxxxxx',password='xxxxxxxx' '//192.168.5.10/unraidbu' '/mnt/remotes/192.168.5.10_unraidbu' This mounts and i can access the files on this mount point. What is even odder... but may point to the issue.... i created for testing an OMV vm, and created an smb share with exactly the same share name and password, and this i can connect to that fine with UD. So problem only to real windows machines. I have tried setting the smb version setting on and off.... no difference. This used to work, but seemed to stop at the time of the recent UD updates.. Lost as what to try next. avon-unraid-diagnostics-20230820-0902.zip

Following the application of the 2023.08.17a update this morning, i can now successfully connect to SMB shares again. I did have to delete existing links and recreate (and unlock the domain account it was using!) but then it worked 1st time! Running 6.12.3

I had that too.... from an old $ Mount that stopped working, and had been deleted. I had to reboot, at which point it was still there but no longer connected to anything... and i could then delete

Have just applied latest Unassigned devices plugin, 2023.08.17 and can confirm $ shares can now be configured. I cannot however connect to an authenticated share. Syslog output: Aug 17 15:29:42 UNRAID unassigned.devices: Mounting Remote Share '//10.1.1.13/Software'... Aug 17 15:29:42 UNRAID unassigned.devices: Mount SMB share '//10.1.1.13/Software$' using SMB 3.1.1 protocol. Aug 17 15:29:42 Avon-UNRAID unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=3.1.1,credentials='/tmp/unassigned.devices/credentials_Software$' '//10.1.1.13/Software$' '/mnt/remotes/10.1.1.13_Software$' Aug 17 15:29:42 Avon-UNRAID kernel: CIFS: Attempting to mount \\10.1.1.13\Software$ Aug 17 15:29:42 UNRAID kernel: CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE Aug 17 15:29:42 UNRAID kernel: CIFS: VFS: \\10.1.1.13 Send error in SessSetup = -13 Aug 17 15:29:42 UNRAID kernel: CIFS: VFS: cifs_mount failed w/return code = -13 Aug 17 15:29:42 UNRAID unassigned.devices: Remote Share '//10.1.1.13/Software$' failed to mount. I can see on the windows server login fail due to bad username/pass .... username looks good on windows event log If i run the mount command manually, but substitute username/password for the credentials file it mounts fine and can be accessed. /sbin/mount -t cifs -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=3.1.1,username=xxxxxx,passowrd=xxxx_Software$' '//10.1.1.13/Software$' If i look to the path where the cred file is in the command.... there is nothing there. Either way. password seems not to be being passed to Windows server.

the $ is the thing that make it a hidden share. All windows admin shares are $ shares (C$ for example) ... I also have an issue where shares that have been mounted before, and now show as invalid, when removed the mount point is still there and working if you look in remotes.... not sure how to get rid of this ghost!!