On 24/01/2017 22:06, Gianluca Cecchi wrote:
On Tue, Jan 24, 2017 at 1:04 PM, Gianluca Cecchi
<gianluca.cecchi@xxxxxxxxx <mailto:gianluca.cecchi@xxxxxxxxx>> wrote:
Hello,
my system is an updated Fedora 25.
A previously working windows share mounted via cifs is not working
now (I have not the details of it but I know only that it is a DFS
share, managed by a cluster of two windows 2012 R2 servers)
After some attempts, I have verified that the critical point seems
to be the "uid=1000" option that I previously used to map
permission of files and to be able to change them.
entry in fstab working
\\my.windows.domain\home\path1\path2\path3 /myshare
cifs noauto,_netdev,credentials=/etc/smbcred_myshare 0 0
entry in fstab not working (verified the same from command line,
doubling the slashes in this case)
\\my.windows.domain\home\path1\path2\path3 /myshare
cifs
noauto,_netdev,forceuid,uid=1000,credentials=/etc/smbcred_myshare
0 0
NOTE: I tried both with and without the forceuid option when using
the uid= one but no go in both.
Of course my linux username is not the same as the username used
in credential file.
If I mount without uid I get all files owned by root and not able
to modify anything in Linux.
Any hint on what to try?
Thanks in advance,
Gianluca
I forgot to say that using the uid option I get this kind of message:
# mount /asishare/
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
#
But no mount takes place...
I am using CIFS to mount a windows share on a NAS device attached to my
router, but I am not using the uid option, instead I am using the user=
and password= options to specify the userid and password that I have
defined on my NAS device. The userid and password also happen to match
my Linux userid and password. With these options I have write access
from Linux and Windows can see the files also. Before adding these two
options I was getting the same issue you are reporting, of Root being
the owner, but Windows had no issues, even though I had specified
internally in the device that it was public. Why do you need the uid
option when you are supplying a credentials file, I would have assumed
the credentials file would be specifying the information that would give
your Linux userid the required access?
Also, if the device you are mounting is on a remote server, could your
issue be that the server no longer gives the users listed in your
credentials file access to the path you are trying to mount?
regards,
Steve
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
