You are here
Luke - Thu, 2010/07/01 - 02:22
I've been working with the Samba Turnkey appliance and I'm trying to set up user disk space quotas for our Network Attached Storage (NAS). Using the webmin mount module and the the smbfs package, I set our NAS to be mounted to a local folder accessible to the user. I then installed the webmin quota module and the quota package. After some wrangling this allowed me to set up user quotas on the local file system.
Unfortunately, the NAS appears as a CIFS and I don't seem to be able to set up a disk quota for it. Does anyone know how I might go about setting this up or where I might be able to look?
Thanks.
Forum:
AFAIK you can only use quota on the local filesystem
I'm pretty sure you can use quotas on remote shares but they need to be done on the local system.
However this is not a definative answer. Please feel free to prove me wrong :)
quotas
How, in your understanding, would I do that?
It may not be possible and/or practical
For this to work you will need for each user to have their own user account on the NAS (ie their own individual CIFS share) which corresponds to the user account on the TKL appliance. Then each individual share would need to be mounted to the file server. The 'quota' package would need to be installed on your NAS (assuming that it runs some version of Linux).
Really though, if all this is possible, it makes the TKL Fileserver appliance more-or-less redundant (at least for individual user shares). If you can do it locally (on your NAS) then there is probably no need to replicate it with the Fileserver appliance - just do it all on your NAS.
For a definative answer I would suggest contacting the manufacturer of your NAS (if they have a user forum that's probably a good start).
Please be aware that this is not something I have any experience with, I just did a bit of googling. From my reading it seemed pretty conclusive that you cannot use quotas on a local system to limit remote CIFS share usage. It may be possible if you can mount the NAS share(s) using NFS (rather than CIFS/SMB).
After re-reading your post I
After re-reading your post I thought I'd ask you about your research.
I haven't been able to find anything that specifically says that I can't set up a quota on a remote drive. (In fact, given the nature of samba and roaming profiles, I'm surprised I haven't found more information one way or another). That said, could you supply me with your sources or the search terms that you used to find your information?
Sorry I don't recall
Please note that in this post I have used the term "quota" (without quotes) to refer to the generic idea of disk quotas and 'quota' (with single quotes) to refer to the specific Linux 'quota' package.
After a bit more google-fu (using combinations of terms such as "file system", filesystem, quota, "disk quota", "quota package", cifs, samba, smb, ubuntu, linux, etc) I still haven't been able to recreate my original findings. So we can have a definative answer on this, I have asked the Ubuntu 'quota' packagers/maintainers/devs a question regarding which file systems are supported. Hopefully they'll reply soon.
Further seaching revealed the SourceForge page for the base app Linux DiskQuota. I have had a fairly extensive search there and come up with pretty much nothing (other than a better understanding of the 'quota' package). I've also done some searching on the Samba site and again found very little. I did find some mention of the use of quotas (on the mailing list archive) and got the (vague) impression that perhaps Samba has its own implementation of a quota system? Unfortunately that was not definative and there was no mention on how one might go about setting it up - the users mentioning it ended up using 'quota' on the local file system of the Samba server. To clarify that, it may be worth signing up to the Samba mailing list and post the specific question yourself.
As for 'quota', it seems that 3 things are required for it to work with a specific file system (FS): The kernel must support (or be patched to support) 'quota' with the specific FS, the version of the 'quota' package must support the specific FS (or again be patched to do so) and finally the FS itself must support 'quota'.
I'm 99% sure that the Samba3 implementation of CIFS/SMB does not support 'quota'. To me this makes perfect sense. To explain my stance here's a brief history: SMB (Server Message Block protocol - the basis of CIFS - Common Internet File System) is much older than 'quota'. In fact its significantly older than Linux itself - SMB was initially developed by IBM circa 1985 for use with PC-DOS. Development was continued by Microsoft (with various partners at different times) after they created MS-DOS (initially a licensed clone of IBM's PC-DOS). In 1996 MS added a range of additonal features to SMB and renamed it CIFS. So SMB/CIFS is a proprietry protocol/filesystem primarily developed by MS. I strongly doubt that at any point they would have been even remotely interested in adding support for a Linux disk quotaing system.
The implementation of SMB/CIFS by Samba3 (and prior) is a reverse engineered version of MS SMB/CIFS. IMO adding additional functionality to the Samba implementation of SMB/CIFS that is not (and will not be) supported by Windows would not make sense. The idea of Samba is to mimic the operation of MS SMB/CIFS as closely as possible and to allow cross platform interactivity, not to build on it. To add features that will probably never be available to Windows (or other) servers and clients does not make sense, especially when Linux-to-Linux network file sharing is much better served by NFS (which does allow for the use of 'quota'). If nothing else, I would think that it would increase the likelihood of issues when mixing Windows and Linux CIFS/SMB servers and clients.
As Samba servers can use 'quota' for shares using local file systems and Windows has its own implementation of a disk quota system it seems unlikely that Samba would implement another quotaing system. The problem you are havng is unique to your usage scenario (namely a Samba server re-serving CIFS file shares from a prioprietry NAS). I wouldn't imagine that your usage scenario is a common one.
Unless you can install Linux to your NAS and/or install Linux packages to it, I still think the best way for you to acheive quotas is to buy a new HDD (for your file server) and find another use for your NAS.
Thanks for your help and
Thanks for your help and time, I much appreciate it. I thought I'd give you some follow up information, just to put an end cap to the issue. The NAS that I'm using is a Buffalo Linkstation, which, theoretically uses a custom Linux kernel. Why it doesn't support NFS is anyone's guess. There are ways to hack the Linkstation to get NFS to work, but I almost bricked it last year trying to install the FreeLink program, so I'm weary of trying again.
As an experiment, I created a test user in Webmin/Samba and gave it a quota on the local file system. I logged onto a Windows machine with this account and then exceeded the space and file quotas. When I logged out, Windows gave me an error about not having enough disk space to save the profile information. This is how I would expect user quotas on the local file system to work, though it doesn't solve my problem
I'll go ahead and post to the Samba mailing list to see if anyone can advise me there.
TKLFS & Quotas
Folks,
At some point I too would like to see some form of Quota implementation built into the fileserver appliance.
Just my three cents.
Dave
Quotas can be setup fairly easily for local filesystems
But I think you are right and that it may be a good idea to include in future editions of the Fileserver appliance.
The only gotcha when setting up quotas is that the folder that they are to be used in must be a separately mounted filesystem (ie partition) and the filesystem used must support quotas. This need for a separate partition may make having quotas as a default component of the TKL Fileserver appliance a bit trickier to setup and the install more complex, especially for new (to Linux) users. AFAIK the only filesystems that support it are native Linux ones such as ext3/4 and NFS. There may be other filesystems that also work but I know many won't (even some native ones eg RieserFS).
Basically the steps are as follows:
I can't give you much advice on the config (as I don't currently have access to system that I can mount an additional partition to to test the Webmin setup). But if Webmin isn't as straight forward as I'd hope it is then you should be able to find plenty of info on how to set it up from the CLI with a quick google. Just remember the current stable TKL appliances are all based on Ubuntu Server 8.04/Hardy. As the quota package is a fairly generic Linux app, even instructions from another Linux distro may still work.
[edit] On the Webmin Wiki there is quite a bit of documentation on mounting filesystems and working with disk quotas using Webmin. Note the example screenshots use the newest version of Webmin with their default theme so it may look a little different to the TKL implimentation of Webmin, but the basics should be the same.
Giving each user there own
Giving each user there own share was my first idea, but unfortunately, there is no way to do that with our NAS.
I'm not having any luck with NFS or NFS4 as they don't support password authentication.
I've been looking into using the smbcquota command. It seems like it ought to be able to set up quotas on remote shares, but I'm not familiar enough with the command to be sure.
NFS4 can be used with authentication
but from what I've read you need to use it in conjunction with SSH or Kerberos. This document looks quite useful in relation to NFS security.
I'm not sure but I think that the smbcquota command leverages the 'quota' package. If not then it may be useful for you. Whilst it may not be directly relevant to your NAS this discussion my give you some ideas. If it is independant of 'quota' then you may even be able to use it on your TKL Fileserver to control the shares on your NAS. But unfortunately I think not because as far as I could gather the smbcquota command still only limits users on a per file system basis (same as 'quota') rather than on a per file share basis.
Ok perhaps another way to skin this cat!
Depending on how many users you have you may be able to create some sort of hack/workaround to achieve your desired outcome.
What about using a virtual filesystem? Imagine an .iso file that is mounted read/write as the user's share. From a bit of searching online I've found that .iso files specifically aren't useful for this, I guess it's because the ISO-9660 standard does not include a read/write feature (after all it was designed for read only CDs). However in my travels I came across this. The first section discusses mounting a file as a file system which I believe would work in your instance. There is a note at the bottom though (and I have also read elsewhere) that read/write loop devices are very resource intensive. Because of this, it is probably not suitable if many users or files are concurrently logged in or being edited (respectively).
OTOH 3.5 internal HDDs are getting so cheap these days, perhaps the most practical way to go would be to just buy an additional drive to specifically use for user shares. If you format it to ext3 then you will have no worries setting up user quotas (as I detailed above for Dave). Then you could use your NAS for onsite backups.
Add new comment