dlandon

Community Developer
  • Posts

    10054
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by dlandon

  1. Looks to be someone's attempt to prevent a buffer overflow intentionally or unintentionally. I suspect one of the parameters being passed in to the function causes the failure - like the buff_start or end_of_buffer pointers are incorrect. Good find. Thank you.
  2. There is an issue with CIFS mounts (remote shares) in 6.12.9 that causes this issue. For the moment downgrade to 6.12.8 until we come up with a solution. Since this appears to be related to Samba (CIFS mounts) or the Kernel, it will have to be fixed with an Unraid release. I haven't been able to address the issue with anything related to how UD mounts remote shares.
  3. I've put some time into troubleshooting UD to see if there is something in the way UD is mounting remote shares. There doesn't seem to be anything that UD does or can do to cause this problem. I'm not one to play the blame game, but as we get into this I believe we are going to find it's related to a change in Samba or a Kernel change causing this. In our beta testing for one of the recent releases, we found an issue with CIFS mounts where 'df' would not report size, used, and free space on a CIFS mount point. When UD sees a CIFS mount with zero space, it disables the mount so UI browsing and other operations could not be performed. UD assumes there is a problem with the mount. It ended up being related to a 'stat' change in the Kernel failing on the CIFS mount. As has been said, this is related to remote mounts through UD. It does not affect the NAS file sharing functionality through SMB. I understand that this is an important functionality for many users and for the moment, downgrading to 6.12.8 is the answer. We will release a new version of Unraid as soon as we have an answer.
  4. I am able to reproduce the issue. It appears when you remote mount a share from a server that is not another Unraid.
  5. Ok. But if you want Unraid to mount them, you'll probably need to add all or part of this to the rules: anongid=100,anonuid=99,all_squash
  6. It's not UD. The remote shares unmounted fine. It's the dockers taking a long time to stop: Mar 27 12:19:06 Apollo root: stopping dockerd ... Mar 27 12:19:07 Apollo root: ... Waiting to die. Mar 27 12:19:08 Apollo root: ... Waiting to die. Mar 27 12:19:09 Apollo root: ... Waiting to die. Mar 27 12:19:10 Apollo root: ... Waiting to die. Mar 27 12:19:11 Apollo root: ... Waiting to die. Mar 27 12:19:12 Apollo emhttpd: shcmd (94): umount --lazy /var/lib/docker Mar 27 12:19:12 Apollo unassigned.devices: Unmounting All Devices... Mar 27 12:21:02 Apollo sshd[1168]: Connection from 192.168.2.35 port 17590 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[29211]: Connection closed by 192.168.2.35 port 17480 Mar 27 12:21:02 Apollo sshd[29211]: Close session: user root from 192.168.2.35 port 17480 id 0 Mar 27 12:21:02 Apollo sshd[29211]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:02 Apollo sshd[29211]: Transferred: sent 154472, received 4672 bytes Mar 27 12:21:02 Apollo sshd[29211]: Closing connection to 192.168.2.35 port 17480 Mar 27 12:21:02 Apollo elogind-daemon[1528]: Removed session c4. Mar 27 12:21:02 Apollo sshd[1170]: Connection from 192.168.2.35 port 17591 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[1172]: Connection from 192.168.2.35 port 17592 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[1168]: Postponed keyboard-interactive for root from 192.168.2.35 port 17590 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1168]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17590 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1168]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17590 ssh2 Mar 27 12:21:02 Apollo sshd[1168]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:02 Apollo elogind-daemon[1528]: New session c5 of user root. Mar 27 12:21:02 Apollo sshd[1170]: Postponed keyboard-interactive for root from 192.168.2.35 port 17591 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1170]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17591 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1170]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17591 ssh2 Mar 27 12:21:02 Apollo sshd[1170]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:03 Apollo elogind-daemon[1528]: New session c6 of user root. Mar 27 12:21:03 Apollo sshd[1172]: Postponed keyboard-interactive for root from 192.168.2.35 port 17592 ssh2 [preauth] Mar 27 12:21:03 Apollo sshd[1172]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17592 ssh2 [preauth] Mar 27 12:21:03 Apollo sshd[1172]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17592 ssh2 Mar 27 12:21:03 Apollo sshd[1172]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:03 Apollo elogind-daemon[1528]: New session c7 of user root. Mar 27 12:21:03 Apollo sshd[1168]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17590 id 0 Mar 27 12:21:03 Apollo sshd[1170]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17591 id 0 Mar 27 12:21:03 Apollo sshd[1172]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17592 id 0 Mar 27 12:21:03 Apollo sshd[1172]: Connection closed by 192.168.2.35 port 17592 Mar 27 12:21:03 Apollo sshd[1172]: Close session: user root from 192.168.2.35 port 17592 id 0 Mar 27 12:21:03 Apollo sshd[1172]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:03 Apollo sshd[1172]: Transferred: sent 3656, received 3232 bytes Mar 27 12:21:03 Apollo sshd[1172]: Closing connection to 192.168.2.35 port 17592 Mar 27 12:21:03 Apollo elogind-daemon[1528]: Removed session c7. Mar 27 12:21:03 Apollo sshd[1170]: Connection closed by 192.168.2.35 port 17591 Mar 27 12:21:03 Apollo sshd[1170]: Close session: user root from 192.168.2.35 port 17591 id 0 Mar 27 12:21:03 Apollo sshd[1170]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:03 Apollo sshd[1170]: Transferred: sent 3656, received 3232 bytes Mar 27 12:21:03 Apollo sshd[1170]: Closing connection to 192.168.2.35 port 17591 Mar 27 12:21:03 Apollo elogind-daemon[1528]: Removed session c6. Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2 has not responded in 180 seconds. Reconnecting... Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:22:22 Apollo unassigned.devices: Unmounting Remote SMB/NFS Share '//10.0.0.2/Dropbox'... Mar 27 12:22:22 Apollo unassigned.devices: Unmount cmd: /sbin/umount -t cifs -f '/mnt/remotes/Dropbox' 2>&1 Mar 27 12:22:22 Apollo unassigned.devices: Successfully unmounted '//10.0.0.2/Dropbox' Mar 27 12:22:43 Apollo unassigned.devices: Unmounting Remote SMB/NFS Share '//10.0.0.2/Dropbox/Pictures'... Mar 27 12:22:43 Apollo unassigned.devices: Unmount cmd: /sbin/umount -t cifs -f '/mnt/remotes/Pictures' 2>&1 Mar 27 12:22:43 Apollo unassigned.devices: Successfully unmounted '//10.0.0.2/Dropbox/Pictures' I think your shutdown timer is set properly to handle this.
  7. The mount points you are trying to mount remotely are not Unraid shares and you are setting the export rules manually for those shares. This is an Unraid share entry in the exports file: "/mnt/user/isos" -fsid=105,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) I suggest you take a look at this entry and compare to your entries and see if changes are needed. I suspect a permissions issue that UD is having trouble with. Check if 'all_squash' makes a difference. As a test, share a normal Unraid share with NFS and try to mount that and see how it goes. I fully understand that you can mount those with other systems. The issue is that the UD NFS client is probably more restrictive about permissions.
  8. That indicates that the port is open. Show a screen shot of the UD page showing the remote shares.
  9. When the server is shutdown, a copy of the disgnostics is saved on the flash at /flash/logs/. Please post that. I need the shutdown sequence.
  10. Give me the output of this command: timeout -s 5 1 bash -c "(echo >/dev/tcp/IP/2049)" change IP to the server IP address.
  11. The "List Shares" for NFS shares uses showmount to list the NFS shares found on the server. That's why it finds them. The server status (online) has changed from being a ping on the server to a check if the port is open. Your server needs to use the standard port (2049) for NFS. Check that your server is using that port. The reason you're just now seeing this is you probably updated UD and the OS at the same time. This changed occurred in UD some time ago.
  12. UD does a sync on the mount point before forcing the unmount. It has a timeout of 10 seconds. It that command times out, the remote share is force unmounted. I suspect a race condition of some sort. Post diagnostics so I can have a closer look.
  13. That's the problem. UD needs to go ahead and unmount the share even if the server goes offline. I'll research and see if I need to apply a fix.
  14. I would remove and readd the remote shares and verify that UD can see the server (Search For Servers) and the NFS share (Load Shares). Use the server name UD finds and don't enter the IP address.
  15. Someone post diagnostics when this occurs so I can investigate further.
  16. You have cache dirs installed. Eirher remove it, or set it up to include only shares you want it to work on. It has a bad habit of caching all shares including UD shares and causes problems like this.
  17. This means the rootshare can be mounted and should be available to mount on an Unraid server. Some more things to try: Try a simpler password on the administrator account. Letters and numbers only. You have multiple IP addresses listed in the testparm output. This is where Samba is listening: interfaces = 192.168.0.6 192.XXX.XXX.6 127.0.0.1 100.XXX.XXX.115 fd7a:115c:a1e0::27a:ae73 Is the server visible on one of these interfaces? You have tailscale installed. Confirm it is set up properly. Can you see the individual shares and can those be mounted? You have a huge amount of plugins installed. One may be interferring. Boot your server in safe mode and try mounting the root share.
  18. Did you turn on the share switch for the rootshare in device settings? It won't be shared unless you turn it on.
  19. No, that is not your problem. Possible reasons for this error could include: Incorrect credentials (username/password) provided for accessing the CIFS share. Insufficient permissions to access the CIFS share from the system where the error occurred. Network connectivity issues preventing access to the CIFS share. Misconfiguration of the mount command or options used for mounting the CIFS share. I don't think 2 or 3 apply because UD shows the remote share as being online and available. 4 is not an issue. That leaves 1 - credentials. Several things to look for: Use UD to search the server and select the correct server from the drop down. Don't enter the IP address. Let UD search for the remote server shares after entering the credentials in UD. If UD does not list the shares, the credentials are an issue, Watch out for special characters. They can cause php issues. Choose the share from the drop down. Don't enter it. You can't use the 'root' user credentials. You are probably overthinking this issue. Let UD work out the details for you. Let it find the server and the share for you and use what it finds.