"shfs/user: shfs_fallocate: fallocate: (95) Operation not supported" and Plex


TDD

Recommended Posts

Hi all.

 

I have seen a few posts about this in the forums but nothing has pointed me to a solution.

 

I can reproduce these log entries every time.  It happens when, via Plex (docker) accesses my "TV" share across two disks.  Plex is set to access "/mnt/user/TV" and the share itself is set just fine to the disks in question and the two folders (both "TV").

 

Everything comes up as it should via Plex.  It doesn't do this for other Plex libraries that are similarly configured across disks (movies, etc.) and through the /mnt/user side of things.

 

Both disks that house the two folders have clean SMART reporting.

 

It doesn't log this issue if I access /mnt/user/TV from the console, or via Windows, or any other way.  Strictly a Plex thing.

 

Nothing shows in the Plex logs either.

 

I haven't moved all the shows to a single drive (and folder) and checked to see if it reproduces under this condition.  Might be my next step.

 

It doesn't seem to be interfering but I just don't like spurious log errors...

 

Help?  Diagnostic attached too.

 

Kev.

 

Feb 19 21:24:05 FS shfs/user: shfs_fallocate: fallocate: (95) Operation not supported

Feb 19 21:24:05 FS shfs/user: shfs_fallocate: fallocate: (95) Operation not supported

Feb 19 21:32:18 FS shfs/user: shfs_fallocate: fallocate: (95) Operation not supported

Feb 19 21:32:18 FS shfs/user: shfs_fallocate: fallocate: (95) Operation not supported

fs-diagnostics-20160219-2154.zip

Link to comment

Well...I guess I do, including the disk shares.  Only about half are exported to SMB.  Just a lot of folders and breakdown therein.  Music, for example under my SONOS is broken out into different folders based on content.

 

Many folders are just for storage and hence get created in the shares (but again, not exported).

 

Does the number of shares have any bearing?  Again, it is only upon Plex access this particular directory structure.

 

Kev.

Link to comment

Well...I guess I do, including the disk shares.  Only about half are exported to SMB.  Just a lot of folders and breakdown therein.  Music, for example under my SONOS is broken out into different folders based on content.

 

Many folders are just for storage and hence get created in the shares (but again, not exported).

 

Does the number of shares have any bearing?  Again, it is only upon Plex access this particular directory structure.

 

Kev.

Usually when I see someone with that many shares they accidentally created them, and I'm not completely convinced you haven't done so with at least some of them.

 

Your diagnostics have been anonymized, so I can't actually see the share names, but some of them have default settings, which is what happens if you don't configure a share, and what will happen when someone accidentally creates a share. And some of the share names seem to end with "(1)" which usually means a name has been duplicated.

 

The reason I say "accidentally" is because unRAID automatically creates user shares for all top level folders from cache and data disks. Sometimes people will create a top level folder using some method other than actually adding a share and so a share gets created. If you have something creating folders at the top level for example, then that will create a share even if you didn't add it as a share yourself. And any share that you don't configure will have default settings.

 

Usually people don't need so many shares, and if they have a lot of miscellaneous stuff to store they will just put it in separate folders within a share instead of creating (either intentionally or accidentally) a lot of separate shares.

 

I am not aware of any limit to the number of shares you can have and whether there is any impact from having so many, just thought it odd and worth mentioning in case this is not what you intended. Even if it is what you intended I think maybe it would be better to reconsider and consolidate some of these top level folders.

 

Back to your initially reported issue: According to your syslog, you don't have a cache drive. Where are you installing your dockers?

 

Link to comment

I do have a lot of top-level shares, and had considered cleaning them up by burying them in one folder at the top instead.

 

My docker runs on a normal drive, 20GB in size.

 

I have been going through each drive and noting spurious folders, going back to the shares area to ensure that all shares are defined explicitly as include or exclude as needed to ensure nothing ends up elsewhere.

 

I am in the midst of Reiser to XFS migration as well so it might cure itself as the folders are recreated?  I am watching for this to see what happens.

 

Many of the shares are set to either non-export or hidden so it is not so zany when I pull up a list of shares from the server...

 

Kev.

Link to comment

I had said I wasn't aware of any impact from having so many user shares, but I think it has to have some perhaps unnoticeable impact each time you start the array, since at that time unRAID discovers all the top level folders, makes them into user shares, and applies the settings from each share's .cfg file stored on the flash if one exists or applies default settings if there isn't a .cfg file for the share. And of course, those .cfg files get created only if you go to a share's page to make any settings and then apply them.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.