Access Denied on 'Large' files?

[Canezar]

Hello there,

I have absolutly no experience with FreeNAS but have access to the admin console and can ssh into the machine with root access, while I am primarily a Windows admin I have some Linux experience and can get around in CLI. The FreeNAS was configured before I was hired and the usual employee who handles it is not available.

We have a CIFS share where users are expected to be able to drop image files into to use as a shared resource, but I've been informed that it has never worked correctly and needs to be fixed. This is what I know so far:

The user has access to the share and subfolders.
Inside these locations, they can create or upload ordinary .txt files without any visible constraints.
They were able to upload a .jpg file that was only 28KB.
When trying to upload larger files, they get hit with Access Denied.
This is true even if we try removing or changing the file extension.
Other users without access restrictions (like root) have no problems uploading files.
When looking at the permissions from a windows machine, the user in question has access through their default group.

Is there some sort of file size limit imposed on the denied user? If so, where should I be looking if I wanted to remove it. Is there any additional information I can try to provide?

Thanks for your time. : )

 

[anodos]

Hello there,

I have absolutly no experience with FreeNAS but have access to the admin console and can ssh into the machine with root access, while I am primarily a Windows admin I have some Linux experience and can get around in CLI. The FreeNAS was configured before I was hired and the usual employee who handles it is not available.

We have a CIFS share where users are expected to be able to drop image files into to use as a shared resource, but I've been informed that it has never worked correctly and needs to be fixed. This is what I know so far:

The user has access to the share and subfolders.
Inside these locations, they can create or upload ordinary .txt files without any visible constraints.
They were able to upload a .jpg file that was only 28KB.
When trying to upload larger files, they get hit with Access Denied.
This is true even if we try removing or changing the file extension.
Other users without access restrictions (like root) have no problems uploading files.
When looking at the permissions from a windows machine, the user in question has access through their default group.

Is there some sort of file size limit imposed on the denied user? If so, where should I be looking if I wanted to remove it. Is there any additional information I can try to provide?

Thanks for your time. : )

Sounds like CIFS is misconfigured. There may be other problems as well. Post your debug file: System -> Advanced -> Save Debug

 

[Canezar]

Sounds like CIFS is misconfigured. There may be other problems as well. Post your debug file: System -> Advanced -> Save Debug

Hey, thanks for replying. Here is what I found there:

Show : Debug Results

Request Method: GET
Request URL: http://<sharename>/system/debug/
Software Version: FreeNAS-9.2.1.5-RELEASE-x64 (80c1d35)
Exception Type: IOError
Exception Value:
[Errno 2] No such file or directory: '/var/tmp/ixdiagnose/ixdiagnose.tgz'
Exception Location: /usr/local/www/freenasUI/../freenasUI/system/views.py in debug, line 542
Server time: Thu, 14 May 2015 12:49:44 -0400
Traceback
Environment:

Software Version: FreeNAS-9.2.1.5-RELEASE-x64 (80c1d35)
Request Method: GET
Request URL: http://<sharename>/system/debug/


Traceback:
File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
107. response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/usr/local/www/freenasUI/../freenasUI/freeadmin/middleware.py" in process_view
158. return login_required(view_func)(request, *view_args, **view_kwargs)
File "/usr/local/lib/python2.7/site-packages/django/contrib/auth/decorators.py" in _wrapped_view
22. return view_func(request, *args, **kwargs)
File "/usr/local/www/freenasUI/../freenasUI/system/views.py" in debug
542. with open(dump, "r") as f:

Exception Type: IOError at /system/debug/
Exception Value: [Errno 2] No such file or directory: '/var/tmp/ixdiagnose/ixdiagnose.tgz'



Request information

GET

No GET data

POST

No POST data

FILES

No FILES data

COOKIES

Variable Value
csrftoken 'cBAlKjojjAYz3S5dB42QqYnqNEf78y8s'
sessionid 'jq1ujzxohe46pvmsljy1118jz723yc19'
fntreeSaveStateCookie 'root%2Croot%2F1%2F7%2Croot%2F55%2F62%2Croot%2F93%2F101%2Croot%2F1%2F2%2Croot%2F55%2F62%2F63%2Croot%2F12'
META

Variable Value
wsgi.multiprocess False
HTTP_REFERER 'http://<sharename>'
REDIRECT_STATUS '200'
SERVER_SOFTWARE 'nginx/1.4.4'
SCRIPT_NAME u''
REQUEST_METHOD 'GET'
PATH_INFO u'/system/debug/'
SERVER_PROTOCOL 'HTTP/1.1'
QUERY_STRING ''
CONTENT_LENGTH ''
HTTP_USER_AGENT 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36'
HTTP_CONNECTION 'keep-alive'
HTTP_COOKIE 'sessionid=jq1ujzxohe46pvmsljy1118jz723yc19; fntreeSaveStateCookie=root%2Croot%2F1%2F7%2Croot%2F55%2F62%2Croot%2F93%2F101%2Croot%2F1%2F2%2Croot%2F55%2F62%2F63%2Croot%2F12; csrftoken=cBAlKjojjAYz3S5dB42QqYnqNEf78y8s'
SERVER_NAME 'localhost'
REMOTE_PORT '52874'
wsgi.url_scheme 'http'
SERVER_PORT '80'
SERVER_ADDR '10.10.26.25'
DOCUMENT_ROOT '/usr/local/etc/nginx/html'
DOCUMENT_URI '/system/debug/'
wsgi.input <flup.server.fcgi_base.InputStream object at 0x80afccd10>
HTTP_HOST '<hostname>'
wsgi.multithread True
REQUEST_URI '/system/debug/'
HTTP_ACCEPT 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
wsgi.version (1, 0)
GATEWAY_INTERFACE 'CGI/1.1'
wsgi.run_once False
wsgi.errors <flup.server.fcgi_base.TeeOutputStream object at 0x80adf4a90>
REMOTE_ADDR '10.10.3.42'
HTTP_ACCEPT_LANGUAGE 'en-GB,en-US;q=0.8,en;q=0.6'
CONTENT_TYPE ''
CSRF_COOKIE u'cBAlKjojjAYz3S5dB42QqYnqNEf78y8s'
HTTP_ACCEPT_ENCODING 'gzip, deflate, sdch'

After some experimenting I was able to get around the problem by assigning the user through Windows permissions directly to the folder they needed to be able to leave files in, but I'd still like to know how to fix it properly.

 

[anodos]

Hey, thanks for replying. Here is what I found there:
After some experimenting I was able to get around the problem by assigning the user through Windows permissions directly to the folder they needed to be able to leave files in, but I'd still like to know how to fix it properly.

Okay. That debug didn't work. :) My intuition is telling me that your CIFS problems may not be the only thing wrong with your server.

Post the following information:

1) Hardware specs of server
2) Output of running "freenas-debug -acghTnsytz" (you can enable SSH and use filezilla to download the file(s) using SFTP). It will be located under /var/tmp/fndebug. I can't remember the output format of this utility. If it's a bunch of files, try zipping them up and attaching them to the thread.
3) Contents of /usr/local/etc/smb4.conf (you can enable SSH and use filezilla to download the file). You can sanitize share names / details if you want.
​

Once you post this info (enclosed in code tags ), then I'll probably ask more questions.

 

[cyberjock]

2) Output of running "freenas-debug -acghTnsytz" (you can enable SSH and use filezilla to download the file(s) using SFTP). It will be located under /var/tmp/fndebug. I can't remember the output format of this utility. If it's a bunch of files, try zipping them up and attaching them to the thread.​

Why not just say "Go to the WebGUI, System -> Advanced -> Save Debug button"?​

 

[anodos]

Why not just say "Go to the WebGUI, System -> Advanced -> Save Debug button"?​

That's what I told him to do initially, but it produced an error message rather than a debug file. It was probably a bug in 9.2.1.5 (which is what he is running). I seem to recall a flurry of 9.2.1.x releases and so it's hard to remember which bugs were where. :D

 

[cyberjock]

That error means his /var is probably full.

So the first thing he needs to do for stability purposes is upgrade to either the latest 9.2.1.x or the 9.3 release. THEN try the problem again and see if it reproduces. There's no reason we (or anyone else) should be debugging a version that is literally over a year old.

 

[anodos]

That error means his /var is probably full.

So the first thing he needs to do for stability purposes is upgrade to either the latest 9.2.1.x or the 9.3 release. THEN try the problem again and see if it reproduces. There's no reason we (or anyone else) should be debugging a version that is literally over a year old.

The upgrade from 9.2.1.5 -> 9.2.1.9 (or whatever) or 9.3 release is non-trivial. It will, from the end-user perspective break CIFS permissions.

Anyway, I was hoping to get hardware and config details before advising to upgrade. The fact that it is running 9.2.1.5 causes me to be very pessimistic. I have a sinking suspicion that the system may be running on inadequate / improper hardware, probably has serious configuration issues, and possibly not even backed up. In short, a ticking time-bomb. If that's the case, then upgrading to the latest versions isn't really the best thing to do.

Alas, the OP disappeared.

 

[cyberjock]

You know, I keep hearing that upgrading from 9.2.1.x to 9.2.1.9 or 9.3 is non-trivial. I've not had that kind of experience myself, and I've probably helped more than 20 people upgrade TrueNAS machines that were on just those versions in the last 2 or 3 months. Some were smaller setups, others were multi vdev monster servers.

I do recognize that the early 9.2.1.x releases were a bit of a mess, but I have a hard time believing that upgrading is non-trivial. My experience has shown no difference between upgrading from any given 9.2.1.x release to either the latest 9.2.1.x release available, or going to 9.3 The only exception is if you are using iSCSI. ESXi seems to sometimes require the iscsi drive to be resignatured, which means that you can't have any VMs running on that volume. This can create problems for companies with large ESXi buildouts. But even then, the issue doesn't seem to be with FreeNAS. The issue seems to be that ESXi is having to resignature the volume for reasons that I am not aware of (and to my knowledge isn't fully understood).

I'm not discounting people's experiences, but I tend to think that the experiences are the result of not using FreeNAS properly (for whatever definition of "properly" was appropriate for the early 9.2.1.x builds that were used on your server).

I've even helped people running pre 9.2.1 releases upgrade to 9.2.1.x+ and, for the most part, they are trouble free as long as permissions were setup properly to start with.

I tend to think that the problem is that people used their servers with some poor bastardized setup that mixed ACLs and Unix permissions and it happened to work. But after switching to a build with Samba4, the need to have it use ACLs exclusively (and properly) made things break for people and as the FreeNAS versions got higher more seatbelts were added narrowing down the ability for said "bastardized setups" to be able to function.

IMO, claiming that upgrading is going to break things (especially permissions) isn't really a good argument to not upgrade IMO. There's some very serious flaws, security updates, memory leaks, etc. in various aspects of FreeNAS until you get to the 9.3 releases that are less than about 2 months old. If your permissions are broken, why not swallow the poison and do the upgrade and fix the stuff that is actually broken instead of arguing against upgrading?

The last question is rhetorical and not directed at anyone in particular. I just don't understand. It's like arguing change is bad as a reason to not accept some newfound tech, then are disappointed when you are left behind by the rest of the world.

Choosing not to upgrade is still a choice. There are consequences to that choice, for better or for worse.