Bug #9385

item "python2.7" is in use

Added by p s over 5 years ago. Updated about 3 years ago.

Closed: Insufficient Info
Cyber Jock
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


1. Create CIFS share and share it out
2. Start copying data to the share via CIFS
3. While data is copying, go to the main FreeNAS menu and double click "Shell"
4. Expand shell to 132x50
5. After a few seconds the transfer stops and there is an error that an item cannot be found.
6. Trying to delete the destination folder via CIFS yields this error (on a mac): "The operation can't be completed because the item "python2.7" is in use"

The only way to delete it is from the command line / shell / ssh.

images.jpeg (7.23 KB) images.jpeg WAT Jordan Hubbard, 04/23/2015 07:50 PM
pzIug.gif (303 KB) pzIug.gif What?! Dave F, 04/23/2015 08:09 PM
wtf.gif (2.29 MB) wtf.gif Dr K K, 04/23/2015 08:26 PM


#1 Updated by Jordan Hubbard over 5 years ago

  • File images.jpeg images.jpeg added
  • Category set to 57
  • Assignee set to John Hixson
  • Target version set to Unspecified

#2 Updated by Jordan Hubbard over 5 years ago

  • Assignee changed from John Hixson to Cyber Jock

Changing assignment to Cyberjock since he's almost certainly the only other person on the planet who could reproduce a bug like this.

#3 Updated by Dr K K over 5 years ago

This is the most amazing bug report I've ever seen.

The OP will either be hailed as a genius, or made fun of for the balance of 2015.

#4 Updated by Dr K K over 5 years ago

OK, on this amazing bug, we have two reliable users in IRC (both canadian, though, so...) that can at least reproduce that the listed steps clearly have a negative impact on the transfer throughput.


#5 Updated by Dave F over 5 years ago


As daft as it sounds, I tried this. 10GB of data over GiB, expanding the shell to 132x50 did in fact slow the transfer down for me. Tried it a couple of times, thought it was a fluke, but nope. Speed bailed.

#6 Updated by Dr K K over 5 years ago

Can we have confirmation from a non-Canadian please?

#7 Updated by Dr K K over 5 years ago


#8 Updated by Jordan Hubbard over 5 years ago

I cannot reproduce the actual error (thank god) but I am seeing some variability with the transfer times. It is hard to correlate that directly with the shell being open, however, as I'm also noticing that CIFS performance in general (at least at 1GbE) tends to be bursty and somewhat difficult to measure the performance of, at least for finder copies on the Mac. I need to find some sort of windows tool that will do metered I/O to a mounted SMB share and try this again - I'm sure such tools exist.

#9 Updated by Cyber Jock over 5 years ago

I don't see a performance drop when copying.

Here when copying from my Win7 Laptop to a TrueNAS 9.3 (latest build) I get a sustained 115-119MB/sec during the transfer of a 5GB test file.

But if I change the shell size to 132x50 when a transfer is not in progress, I get a new shell of the new size within about 2 seconds. If a transfer is in progress, it takes 10 seconds or more to get the new shell unless the transfer finishes. If the transfer finishes, then I get the new shell size within about 2 seconds.

So I tend to think that something programmatically is related. But what the hell it is is totally beyond me. I blame Jordan for this one. This sounds like some kind of super-bug he'd slip in to see who in the company is a badass programmer and can catch it. That person gets a 10% payraise this year. ;)

It is really weird how the python 2.7 message comes up for the OP though. Samba doesn't have the code to tell you what is using a file remotely, only that a file is in use (by another user, obviously). At least, unless I'm mistaken about this. So I tend to think this is somehow related to a locally installed python package and a local python 2.7 install is touching things it shouldn't.

Edit: Ok, it is possible that the html code necessary to run the shell is queued up behind the Samba transfer since I'm so close to saturation speed for Gb LAN. I could try to find a way to test this I think...

#10 Updated by p s over 5 years ago


Did some further testing and there are 2 findings:

First, opening up the shell does indeed slow things down.

Second, I believe (i.e.: I'm not sure) that this problem has to do with path length. If the directory tree being copied over contains files with a deep path length, this python error occurs and there's no way to delete it from the freenas box (other than via shell).

All files are all accessible on the mac but it looks like Samba may be having issues with them. I checked some of the paths and they are indeed long, but shorter than 255 characters.

#11 Updated by Cyber Jock over 5 years ago

Can you provide a debug file from your FreeNAS system? This can be obtained by going to System -> Advanced -> Save Debug.

Edit: Also unless we can get enough information to reproduce this in-house we're going to have to close this to cannot reproduce.

#12 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Unscreened to Screened

#13 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Screened to 15

#14 Updated by Cyber Jock over 5 years ago

Haven't gotten the debug file in 7 days, so closing this to insufficient information.

#15 Updated by Jordan Hubbard over 5 years ago

  • Status changed from 15 to Closed: Insufficient Info

#16 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF