Windows 7 Network Shared on HDA Size Wrong

[jaybea]

Windows has decided that the shares on my HDA are all 2Mb and only have 1Mb of this free. This means that I have been having problems saving some files to my HDA because Windows reports that there is not enough room (although it seems to let me drag files into the folder.

GoodSync for Windows, on the other hand, does not have a problem with the size of the shares and correctly reports size and space: \\HDA\Backup_julian NTFS, Free: 869 GB, Total: 916 GB / On disk smb://HDA/Backup_julian space required for sync is 70.0 KB, you have 869 GB

Any ideas? Refreshing the explorer window in Windows does not do any good, and the wrong size report has survived a reboot. There are no quotas set up.

Amahi 4.0 / Febora 14 x64

[bigfoot65]

Not sure what is going on here. Does the Windows 7 work group match the HDA work group?

[jaybea]

I have done a bit more investigation but cannot get Windows to report the correct Network Drive sizes, even after a reboot of the HDA. The workgroup name is the same across all the devices, but it does appear to be a HDA problem, as all the machines I have tried report the shares as 2Mb capacity and 1Mb free.

I cannot find any references to similar problems from Google searches, so it has me stumped! It might be something to do with the SMB config, so I will have a look at the config files later.

[jaybea]

It appears to be a Greyhole issue. Looking at /etc/samba/smb.conf, the affected shares (those that show 1Mb free on 2Mb total) were all part of a Greyhole pool. I started off with this and then removed them from the Pool and turned Greyhole back off again, as it did not really suit the way I work with the HDA. All the affected shares have the following lines in the appropriate section in smb.conf:

[share_name]
...
dfree command = /usr/bin/greyhole-dfree
vfs objects = greyhole

I mapped a share that had never been in the Greyhole pool and Windows reports the capacity and free space correctly.

I guess I can get rid of the problem by commenting out the two lines in each of the share sections in smb.conf. [Update] No, that does not work!

[bigfoot65]

Greyhole may not have had enough time to react to your changes before you shut it off. Recommend you turn it back on, the do greyhole --fsck from command line as root and see what occurs.

You can monitor progress by looking at /var/log/greyhole.log

[jaybea]

I added one drive back into the pool and the correct share sizes / free space appear in Windows again. Running greyhole --fsck resulted in an error about timezone settings - I recall this appearing in a log during installation.

PHP Warnng: date_default_timezone_get()

I have now removed all the shares from Greyhole and they have gone from smb.conf this time. It looks like I turned off Greyhole the wrong way previously, as I removed drives from the pool first and this left the shares with the Greyhole lines in smb.conf because the Storage Pool option under the share disappeared. Since there were no pooled drives, Greyhole could not run - greyhole.log was full of messages telling me this.

Greyhole has finished processing files, but I will leave it with the one drive in the pool until tomorrow evening and then deselect the drive and see what happens.

[bigfoot65]

Awesome, that's what I was afraid might of happened. Ensure you follow the wiki guidance when you disable greyhole.

http://wiki.amahi.org/index.php/Greyhol ... e_Greyhole

[jaybea]

The problems appear to be caused by disabling things in the wrong order. Would it be possible to add something to the script that runs when drives are deselected from the pool that would check for Greyhole entries in smb.conf and either remove them or warn the user to deselect the shares first? It might avoid catching out other users who, like me, do not read the Wiki fully. I can add a bit to the wiki about the process of turning off Greyhole once I have completed the process of turning it off and checked that the process works ok.

[bigfoot65]

Probably not a bad idea. Please submit a bug as a feature request at bugs at amahi dot org?

As for the wiki, updates are always welcome