[Desktop-packages] [Bug 1815395] Re: GVFS-SMB write problems to SMB2 shares
** Changed in: gvfs (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1815395 Title: GVFS-SMB write problems to SMB2 shares Status in gvfs package in Ubuntu: Invalid Bug description: Summary: I believe there’s a bug in GVFS-SMB (or its implementation in Nautilus) that manifests when writing to SMB2 shares. It occurs inconsistently (but enough to be annoying) in everyday use, but it can be replicated consistently with a simple echo command redirected to a file on the share. This doesn’t happen when using the ‘mount’ command to connect to SMB2 shares. It also doesn’t happen when making an SMB1 connection through Nautilus OR mount. I’ve also tested this against 2 different SMB servers (a Synology DS216J and a share on a Win7 Pro system) and the results are consistent so I don’t believe it’s a server side issue. I don’t know enough about this part of the system to identify where the issue is or fix it, but I’ve included data below to show the basis for my assertions above. The workaround is either going back to SMB1 or mounting my shares with the mount command, but I was hoping someone could take this on and fix it long-term. As Microsoft progressively phases out SMB1, I think this will eventually become a wider scale problem so now would be an opportune time to address it. If there’s any further data I can provide, please let me know. Also, I’m sorry this bug report is so long, but I’m erring on the side of too much detail rather than too little. Detail: On my Ubuntu 18.04 system, when I attempt to echo a string into a file on a GVFS mounted share (left hand nav of Nautilus + Other Locations) and that share is configured to SMB1 (client side left to negotiate, server side locked to SMB1) this works as expected. I tested against SMB shares on both a Synology Diskstation DS216J NAS and a Windows 7 Professional workstation. When I was on Ubuntu 16.04 that was SMB1 only out of the box I didn’t know this problem even existed. Now that I’m on Ubuntu 18.04 and my share was willing to make connection at SMB2 I started to have weird, inconsistent disk problems. Much troubleshooting and analysis later, I can recreate this issue consistently with a simple echo command to a file on the share. To the SMB share on a Synology Diskstation NAS set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB1-GVFS- NAS.txt The command executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the NAS file share. To the SMB share on a Windows 7 Professional workstation set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB1-GVFS-Win7.txt The command also executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the “videos” file share on the Win7 workstation. I also took PCAPs of this occurring (attached). What they show is about what I would expect for this operation. Client SMB pings the server in packet 1 who responds in packet 2, queries info on the folder in packet 4 and gets some basic info back in packet 5, queries the filename (to make sure it doesn’t already exist) several times (not sure why), each time getting a name not found reply in packets 6 through 17, then creates the file in packet 18, gets back a success message in packet 19, queries info on the new file in packet 20, gets a success response in packet 21, writes the contents in packet 22, gets a good response in packet 23, queries the file one more time (presumably to make sure the new size is good) in packet 24, gets a response with the info in packet 25, requests the handle be closed in packet 26, and gets an OK to that in packet 27. This is all wonderful. Perhaps slightly inefficient, but I don’t know what’s going on under the hood, so who am I to judge? When I switch to SMB2 on the server side and reconnect via GVFS using Nautilus, things fall apart. To the SMB share on a Synology Diskstation NAS set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB2-GVFS- NAS.txt returns bash: /run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare /Test-File-SMB2-GVFS-NAS.txt: Invalid argument The file is where I expected it, but it is 0 bytes. To the SMB share on a Windows 7 Professional workstation set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb-
[Desktop-packages] [Bug 1815395] Re: GVFS-SMB write problems to SMB2 shares
Well, I'm not sure what the issue or fix was, but this issue can be closed. I posted the bug to the GVFS list and, amongst other suggestions, one of the maintainers noticed an error in the GVFS debug log of 2 malformed parameters in smb.conf min client protocol and max client protocol (vs the correct client min protocol and client max protocol). These nonsense parameters were also both set to SMB3 so the first thing I did was remove them from smb.conf before doing the other tests recommended. However, now my repeatable "issue" scenario writes the files properly (and the traces show a perfectly good response to the file info request that repeatedly returned access denied errors before, BUT the file creation parameter values are now different for no reason I can figure out). I tried adding the parameter lines back, as they were before, but I still can't recreate the issue. I also tried "fixing" those bad parameter lines and it prevented me from connecting to my SMB2 share at all, which I would expect when the client side is locked to SMB3. So after I pulled the lines again to let the client side negotiate naturally, I can't get the issue to happen again after repeated tests with different programs, some of which had consistent write problems and some of which had intermittent write problems. I didn't do any updates to the system in between when I posted this and when I "fixed" it and the one change I DID make I reversed, but it didn't cause the problem to recur. I suppose this is why I wanted to see if anyone could replicate this. I would bet now that they couldn't but I doubt I'll ever know what the actual issue was, now. Anyway, I'm closing this bug. Sorry for the false alarm. :) Thanks, Scott -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1815395 Title: GVFS-SMB write problems to SMB2 shares Status in gvfs package in Ubuntu: New Bug description: Summary: I believe there’s a bug in GVFS-SMB (or its implementation in Nautilus) that manifests when writing to SMB2 shares. It occurs inconsistently (but enough to be annoying) in everyday use, but it can be replicated consistently with a simple echo command redirected to a file on the share. This doesn’t happen when using the ‘mount’ command to connect to SMB2 shares. It also doesn’t happen when making an SMB1 connection through Nautilus OR mount. I’ve also tested this against 2 different SMB servers (a Synology DS216J and a share on a Win7 Pro system) and the results are consistent so I don’t believe it’s a server side issue. I don’t know enough about this part of the system to identify where the issue is or fix it, but I’ve included data below to show the basis for my assertions above. The workaround is either going back to SMB1 or mounting my shares with the mount command, but I was hoping someone could take this on and fix it long-term. As Microsoft progressively phases out SMB1, I think this will eventually become a wider scale problem so now would be an opportune time to address it. If there’s any further data I can provide, please let me know. Also, I’m sorry this bug report is so long, but I’m erring on the side of too much detail rather than too little. Detail: On my Ubuntu 18.04 system, when I attempt to echo a string into a file on a GVFS mounted share (left hand nav of Nautilus + Other Locations) and that share is configured to SMB1 (client side left to negotiate, server side locked to SMB1) this works as expected. I tested against SMB shares on both a Synology Diskstation DS216J NAS and a Windows 7 Professional workstation. When I was on Ubuntu 16.04 that was SMB1 only out of the box I didn’t know this problem even existed. Now that I’m on Ubuntu 18.04 and my share was willing to make connection at SMB2 I started to have weird, inconsistent disk problems. Much troubleshooting and analysis later, I can recreate this issue consistently with a simple echo command to a file on the share. To the SMB share on a Synology Diskstation NAS set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB1-GVFS- NAS.txt The command executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the NAS file share. To the SMB share on a Windows 7 Professional workstation set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB1-GVFS-Win7.txt The command also executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the “videos” file share on the Win7 workstation. I also took
[Desktop-packages] [Bug 1815395] Re: GVFS-SMB write problems to SMB2 shares
Sorry, spoke too soon. I'm not sure which status to change this to. It was never confirmed by anyone else, but the traces definitely showed something bad happening. Any suggestions what I should set the status to in order to properly file it away? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1815395 Title: GVFS-SMB write problems to SMB2 shares Status in gvfs package in Ubuntu: New Bug description: Summary: I believe there’s a bug in GVFS-SMB (or its implementation in Nautilus) that manifests when writing to SMB2 shares. It occurs inconsistently (but enough to be annoying) in everyday use, but it can be replicated consistently with a simple echo command redirected to a file on the share. This doesn’t happen when using the ‘mount’ command to connect to SMB2 shares. It also doesn’t happen when making an SMB1 connection through Nautilus OR mount. I’ve also tested this against 2 different SMB servers (a Synology DS216J and a share on a Win7 Pro system) and the results are consistent so I don’t believe it’s a server side issue. I don’t know enough about this part of the system to identify where the issue is or fix it, but I’ve included data below to show the basis for my assertions above. The workaround is either going back to SMB1 or mounting my shares with the mount command, but I was hoping someone could take this on and fix it long-term. As Microsoft progressively phases out SMB1, I think this will eventually become a wider scale problem so now would be an opportune time to address it. If there’s any further data I can provide, please let me know. Also, I’m sorry this bug report is so long, but I’m erring on the side of too much detail rather than too little. Detail: On my Ubuntu 18.04 system, when I attempt to echo a string into a file on a GVFS mounted share (left hand nav of Nautilus + Other Locations) and that share is configured to SMB1 (client side left to negotiate, server side locked to SMB1) this works as expected. I tested against SMB shares on both a Synology Diskstation DS216J NAS and a Windows 7 Professional workstation. When I was on Ubuntu 16.04 that was SMB1 only out of the box I didn’t know this problem even existed. Now that I’m on Ubuntu 18.04 and my share was willing to make connection at SMB2 I started to have weird, inconsistent disk problems. Much troubleshooting and analysis later, I can recreate this issue consistently with a simple echo command to a file on the share. To the SMB share on a Synology Diskstation NAS set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB1-GVFS- NAS.txt The command executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the NAS file share. To the SMB share on a Windows 7 Professional workstation set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB1-GVFS-Win7.txt The command also executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the “videos” file share on the Win7 workstation. I also took PCAPs of this occurring (attached). What they show is about what I would expect for this operation. Client SMB pings the server in packet 1 who responds in packet 2, queries info on the folder in packet 4 and gets some basic info back in packet 5, queries the filename (to make sure it doesn’t already exist) several times (not sure why), each time getting a name not found reply in packets 6 through 17, then creates the file in packet 18, gets back a success message in packet 19, queries info on the new file in packet 20, gets a success response in packet 21, writes the contents in packet 22, gets a good response in packet 23, queries the file one more time (presumably to make sure the new size is good) in packet 24, gets a response with the info in packet 25, requests the handle be closed in packet 26, and gets an OK to that in packet 27. This is all wonderful. Perhaps slightly inefficient, but I don’t know what’s going on under the hood, so who am I to judge? When I switch to SMB2 on the server side and reconnect via GVFS using Nautilus, things fall apart. To the SMB share on a Synology Diskstation NAS set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB2-GVFS- NAS.txt returns bash: /run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare /Test-File-SMB2-GVFS-NAS.txt: Invalid argument The file is where I expected it, but it is 0
[Desktop-packages] [Bug 1815395] Re: GVFS-SMB write problems to SMB2 shares
Will do. I wanted to post here before cross-posting it in case the issue was something to do with the Ubuntu implementation of GVFS and not GVFS itself. I was also kind of hoping someone could do my tests to confirm this is actually a bug and not some craziness that only affects me but I suppose the GVFS folks could do that, too. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1815395 Title: GVFS-SMB write problems to SMB2 shares Status in gvfs package in Ubuntu: New Bug description: Summary: I believe there’s a bug in GVFS-SMB (or its implementation in Nautilus) that manifests when writing to SMB2 shares. It occurs inconsistently (but enough to be annoying) in everyday use, but it can be replicated consistently with a simple echo command redirected to a file on the share. This doesn’t happen when using the ‘mount’ command to connect to SMB2 shares. It also doesn’t happen when making an SMB1 connection through Nautilus OR mount. I’ve also tested this against 2 different SMB servers (a Synology DS216J and a share on a Win7 Pro system) and the results are consistent so I don’t believe it’s a server side issue. I don’t know enough about this part of the system to identify where the issue is or fix it, but I’ve included data below to show the basis for my assertions above. The workaround is either going back to SMB1 or mounting my shares with the mount command, but I was hoping someone could take this on and fix it long-term. As Microsoft progressively phases out SMB1, I think this will eventually become a wider scale problem so now would be an opportune time to address it. If there’s any further data I can provide, please let me know. Also, I’m sorry this bug report is so long, but I’m erring on the side of too much detail rather than too little. Detail: On my Ubuntu 18.04 system, when I attempt to echo a string into a file on a GVFS mounted share (left hand nav of Nautilus + Other Locations) and that share is configured to SMB1 (client side left to negotiate, server side locked to SMB1) this works as expected. I tested against SMB shares on both a Synology Diskstation DS216J NAS and a Windows 7 Professional workstation. When I was on Ubuntu 16.04 that was SMB1 only out of the box I didn’t know this problem even existed. Now that I’m on Ubuntu 18.04 and my share was willing to make connection at SMB2 I started to have weird, inconsistent disk problems. Much troubleshooting and analysis later, I can recreate this issue consistently with a simple echo command to a file on the share. To the SMB share on a Synology Diskstation NAS set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB1-GVFS- NAS.txt The command executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the NAS file share. To the SMB share on a Windows 7 Professional workstation set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB1-GVFS-Win7.txt The command also executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the “videos” file share on the Win7 workstation. I also took PCAPs of this occurring (attached). What they show is about what I would expect for this operation. Client SMB pings the server in packet 1 who responds in packet 2, queries info on the folder in packet 4 and gets some basic info back in packet 5, queries the filename (to make sure it doesn’t already exist) several times (not sure why), each time getting a name not found reply in packets 6 through 17, then creates the file in packet 18, gets back a success message in packet 19, queries info on the new file in packet 20, gets a success response in packet 21, writes the contents in packet 22, gets a good response in packet 23, queries the file one more time (presumably to make sure the new size is good) in packet 24, gets a response with the info in packet 25, requests the handle be closed in packet 26, and gets an OK to that in packet 27. This is all wonderful. Perhaps slightly inefficient, but I don’t know what’s going on under the hood, so who am I to judge? When I switch to SMB2 on the server side and reconnect via GVFS using Nautilus, things fall apart. To the SMB share on a Synology Diskstation NAS set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB2-GVFS- NAS.txt returns bash: /run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare
[Desktop-packages] [Bug 1815395] [NEW] GVFS-SMB write problems to SMB2 shares
Public bug reported: Summary: I believe there’s a bug in GVFS-SMB (or its implementation in Nautilus) that manifests when writing to SMB2 shares. It occurs inconsistently (but enough to be annoying) in everyday use, but it can be replicated consistently with a simple echo command redirected to a file on the share. This doesn’t happen when using the ‘mount’ command to connect to SMB2 shares. It also doesn’t happen when making an SMB1 connection through Nautilus OR mount. I’ve also tested this against 2 different SMB servers (a Synology DS216J and a share on a Win7 Pro system) and the results are consistent so I don’t believe it’s a server side issue. I don’t know enough about this part of the system to identify where the issue is or fix it, but I’ve included data below to show the basis for my assertions above. The workaround is either going back to SMB1 or mounting my shares with the mount command, but I was hoping someone could take this on and fix it long-term. As Microsoft progressively phases out SMB1, I think this will eventually become a wider scale problem so now would be an opportune time to address it. If there’s any further data I can provide, please let me know. Also, I’m sorry this bug report is so long, but I’m erring on the side of too much detail rather than too little. Detail: On my Ubuntu 18.04 system, when I attempt to echo a string into a file on a GVFS mounted share (left hand nav of Nautilus + Other Locations) and that share is configured to SMB1 (client side left to negotiate, server side locked to SMB1) this works as expected. I tested against SMB shares on both a Synology Diskstation DS216J NAS and a Windows 7 Professional workstation. When I was on Ubuntu 16.04 that was SMB1 only out of the box I didn’t know this problem even existed. Now that I’m on Ubuntu 18.04 and my share was willing to make connection at SMB2 I started to have weird, inconsistent disk problems. Much troubleshooting and analysis later, I can recreate this issue consistently with a simple echo command to a file on the share. To the SMB share on a Synology Diskstation NAS set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB1-GVFS-NAS.txt The command executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the NAS file share. To the SMB share on a Windows 7 Professional workstation set to SMB1: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB1-GVFS-Win7.txt The command also executes with no feedback (other than the return of the prompt awaiting the next command) and the file of the name specified with the contents specified appears at the root of the “videos” file share on the Win7 workstation. I also took PCAPs of this occurring (attached). What they show is about what I would expect for this operation. Client SMB pings the server in packet 1 who responds in packet 2, queries info on the folder in packet 4 and gets some basic info back in packet 5, queries the filename (to make sure it doesn’t already exist) several times (not sure why), each time getting a name not found reply in packets 6 through 17, then creates the file in packet 18, gets back a success message in packet 19, queries info on the new file in packet 20, gets a success response in packet 21, writes the contents in packet 22, gets a good response in packet 23, queries the file one more time (presumably to make sure the new size is good) in packet 24, gets a response with the info in packet 25, requests the handle be closed in packet 26, and gets an OK to that in packet 27. This is all wonderful. Perhaps slightly inefficient, but I don’t know what’s going on under the hood, so who am I to judge? When I switch to SMB2 on the server side and reconnect via GVFS using Nautilus, things fall apart. To the SMB share on a Synology Diskstation NAS set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=diskstation\,share\=fileshare/Test-File-SMB2-GVFS-NAS.txt returns bash: /run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare /Test-File-SMB2-GVFS-NAS.txt: Invalid argument The file is where I expected it, but it is 0 bytes. To the SMB share on a Windows 7 Professional workstation set to SMB2: echo "This is a test." > /run/user/1000/gvfs/smb- share\:server\=hp_laptop\,share\=videos/Test-File-SMB2-GVFS-Win7.txt returns bash: /run/user/1000/gvfs/smb-share:server=hp_laptop,share=videos/Test- File-SMB2-GVFS-Win7.txt: Invalid argument Again, the file is there in the right location, but it is 0 bytes. Going to take a look at the PCAPs, it’s pretty clear what’s happened, but less clear why. The PCAPs were consistent between the NAS and the Win7 Pro workstation. So the client requests a file with no name (presumably as shortcut for pwd) be opened in
