CLOSED: Not enough space error

[jkbuckethead]

Recently I've been getting errors when using Windows 7 to move files from local drives to my amahi shares. The file transfers fail, and I get an error stating the there is not enough space or the file is too large for the system. The specific error text varies depending upon the source, i.e. windows explorer versus teracopy, but they are always related to file size. The file size itself seems to be irrelevant; there doesn't seem to be a definite size threshold like 2GB or 4GB. Sometimes even small files return an error.

Last night I tried to move about 500 GB of varying size video files. When I viewed the results they were all over the place. Files as small as 693MB failed while larger 4.27GB files succeeded. The files were moved continuously as one batch so there would have been very little time for the server to catch up by moving files from the landing zone to pool storage. Below is just a small example of a few files in sequence that don't make sense. Files of the same size both succeeded and failed in quick succession. I have confirmed that I these are not file path length problems.

3.97GB Success
3.97GB Failed - File is too large for this file system
8.59GB Success
3.97GB Success
8.60GB Failed - File is too large for this file system

The rate of failure versus success varied, but not with any apparent reason. There was a stretch of 1.5-1.8GB files in the middle of the batch where nearly all failed, and a few runs where most would succeed, but overall the success rate varied between 40 and 60% from the start to the end of the batch.

The problem also does not seem to be directly related to the files themselves. When I moved the failed files again, many of them moved successfully. Using nothing but files that failed on the first try, I got the same 40-60% success rate.

I have found similar error reports on the forum, but they all traced back to default share locations and a full OS partition. Solutions discussed there don't seem to apply since I have a 2TB disk dedicated to my landing zone. Currently the partition is formatted as EXT4, and only 4% of the drive is in use. The line below is the result of a "df -Th" command via ssh:

dev/sdj1 ext4 1.8T 59G 1.7T 4% /var/hda/files/drives/disklz

I have a pretty large storage pool, and amahi disk stats indicates 23TB free for shares. I know this is shared across all shares, but clearly I should have enough space to transfer a few hundred GB.

Any help will be appreciated. Thanks.

[bigfoot65]

It could be due to the size of your Greyhole LZ.

There needs to be sufficient space there in order to support the transfer.

Maybe do a test and try transferring a few large files, then once verified that they have been picked up by Greyhole, do a few more.

Until Greyhole picks them up and replaces the file in the share with a symbolic link, it will tie up space on your LZ.

[jkbuckethead]

That's just it, my LZ is on a 2TB partition that is not part of my storage pool, and currently has 1.7TB free. I intentionally put the LZ on a sizable partition because on an earlier iteration of my server I experienced the problem of filling the disk during large transfers, before they could be moved to pool disks. Also, it isn't only with large transfers. I tried moving single files, and sometimes it works, sometimes it doesn't. That's what makes it so strange.

Is the size of the landing zone controlled by something other than the available space on its partition?

[bigfoot65]

Ok so LZ shouldn't be a problem.

It be a firewall issue with your client.

Check that share permissions are set correctly. Do:

Code: Select all

ls -al /var/hda/files

[jkbuckethead]

Not sure what I should be looking for, but the results are below. Is this good or bad?

• [root@localhost ~]# ls -al /var/hda/files
  total 0
  drwxr-xr-x. 3 root root 20 Apr 6 20:58 .
  drwxr-xr-x. 12 root root 152 Mar 27 23:20 ..
  drwxr-xr-x 25 root root 332 Mar 28 01:04 drives

[bigfoot65]

Ownership permissions for /var/hda/files should be your first admin user:users not root.

Also it appears your shares are mounted in a different location. I presume on the other hard drives.

[jkbuckethead]

Yes, my shares are on another drive. When I perform the same command on my landing zone drive (ls -al /var/hda/files/drives/drivelz) I get the following. It's seems strange that most are owned by me, but one is root. If I recall correctly, the TV share is one of the original default shares. Even if it isn't, uhd_4k is a new share, and it's owned by me.

ls -al /var/hda/files/drives/drivelz

drwxrwxrwx 3 beeaitch users 51 Apr 6 22:09 books
drwxrwxrwx 2 beeaitch users 6 Mar 28 00:30 docs
drwxrwxrwx 6 beeaitch users 69 Apr 9 13:21 movies
drwxrwxrwx 2 beeaitch users 6 Mar 28 00:30 music
drwxrwxrwx 2 beeaitch users 6 Mar 28 00:31 pictures
drwxrwxrwx 2 beeaitch users 6 Mar 28 00:31 public
drwxrwxrwx 196 root root 8192 Apr 7 16:19 tv
drwxrwxrwx 4 beeaitch users 28 Mar 28 04:20 uhd_4k
drwxrwxrwx 6 beeaitch users 68 Mar 28 04:22 videos

My intermittent problems copying files to the HDA are not limited to the one share owned by root. Except for the intermittent failures I can add, move and change files on any share. Is share ownership really the issue?

Why would one share be root when the others are not?

How do I change it?

[bigfoot65]

How do I change it?

Code: Select all

sudo chown -R beeaitch:users /var/hda/files/drives/drivelz

Also might want to do the permissions function on each share as shown in the Math shares with users wiki page. Click on the icon next to Permissions.

All else looks good, so not sure what else could be causing the issue.

[jkbuckethead]

In addition to trying to write to the HDA using windows, I tried writing a file to the HDA using file station on my synology NAS. This would remove my windows PC from the equation, but this also failed

To rule out systemic networking issues I rebooted all my computers and network hardware. This did nothing. I then replaced my network switch, but still nothing. I also switched the HDA to a different port with a different cable, and unplugged every network cable not currently in use. To rule out a bad NIC or driver issue on my HDA motherboard, I connected a USB NIC that I had handy. The USB NIC was recognized by the HDA and functions just fine. Unfortunately, though I can access the HDA and read files, I still cannot write to the HDA using the alternate NIC.

In spite of all my efforts, I'm still having no luck moving files to the HDA. The problem certainly appears limited to the HDA. I can read and write files to and from my PC and synology NAS just fine. What's most frustrating is that until a week or so ago, I had no trouble with the HDA. I haven't made any overt changes to the HDA or my network in that time. I hate to do it, but I might do a fresh install this weekend. Hopefully the problems will not persist.

[bigfoot65]

Sorry I have not been much help.

Sure would like to figure out the issue.

Please post your /etc/fstab file contents. Might be a clue there.

Also provide the URL for:

Code: Select all

apaste --sysinfo