Windows Network Drive Linux монтирования требует sudo после монтирования

Question

Я могу смонтировать диск в Linux с помощью sudo.

sudo mount \
    -t cifs \
    -o 'vers=3.0,username=myuser,domain=mydomain' \
    '//windows-ip/share-folder' ~/testmount/

Это прекрасно работает, проблема в том, что когда я захожу в ~/testmount и делаю что-то вроде mkdir он говорит:

mkdir: cannot create directory ‘bkup’: Permission denied

Это будет работать, если я использую sudo У нас будет автоматический скрипт в cronjob для записи файлов на эти монтирования, поэтому мы должны иметь возможность писать на монтирования без sudo .

Так что после монтирования я не могу добавлять файлы в эту папку, если не использую sudo и в этом проблема.

Кажется, моя проблема очень похожа на эту, но решения для нее не сработали:

https://unix.stackexchange.com/questions/231230/mount-successful-directory-accessible-but-cannot-do-operations-cp-mkdir-etc

Кто-то предположил, что проблема заключалась в том, что я использовал sudo для его монтирования, и поэтому мне пришлось использовать sudo, чтобы что-то изменить в нем (даже если мне не нужно использовать sudo для чтения содержимого в нем).

Итак, я нашел ответы, подобные этим:

https://unix.stackexchange.com/questions/365308/use-mount-o-with-a-non-root-user https://wiki.ubuntu.com/MountWindowsSharesPermanently

Я даже пытался реализовать предложенные решения, но так и не смог заставить их работать.

В моем файле etc/fstab есть такая строка:

//windows-ip/share-folder \
/home/mysuer/testmount \
cifs \ 
uid=myuser,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

При вышеописанной настройке, когда я пытаюсь запустить mount без sudo, я получаю сообщение об ошибке:

$ mount ~/testmount
mount: only root can mount //10.1..../shared on /home/.../testmount

Причина, по которой мне нужно иметь возможность писать в эти подключенные папки без sudo, потому что у нас будет автоматическая система сохранения файлов, и я не думаю, что она должна использовать sudo, и я даже не знаю, может ли она, если бы мы этого хотели ,

Я на 7 центов. Возможно, вы не можете поместить опцию 'domain' в fstab, я не знаю. Кто-нибудь может мне с этим помочь?

Answer 1

Монтирование и последующий доступ - это две разные вещи.

Чтобы разрешить пользователям монтировать, четвертое поле в вашем fstab должно содержать user , например user,uid=myuser,… . Смотри man 5 fstab . Возможно, вам это не нужно, продолжайте читать.

Вы даете опцию uid=myuser . Из man 8 mount.cifs:

uid=arg
устанавливает uid, которому будут принадлежать все файлы или каталоги в смонтированной файловой системе, когда сервер не предоставляет информацию о владельце. Он может быть указан как имя пользователя или числовой идентификатор пользователя. Если не указан, по умолчанию используется uid 0 . mount.cifs должен иметь версию 1.10 или выше, чтобы поддерживать указание идентификатора пользователя в нечисловой форме.

Еще один фрагмент:

mount.cifs -V отображает версию помощника по монтированию cifs.

Если uid= указано правильно, монтирование с sudo не должно переопределять его; так что вам может даже не понадобиться опция user в fstab . Может быть, вы были почти там, когда вы использовали uid= но вы сосредоточились на том, чтобы не использовать sudo . Есть еще одна вещь, хотя. Еще один фрагмент:

Основной протокол CIFS не предоставляет информацию о владельце Unix или режим для файлов и каталогов. Из-за этого файлы и каталоги, как правило, будут принадлежать тем значениям, которые установлены в параметрах uid= или gid= , и для них будут заданы разрешения по умолчанию для file_mode и dir_mode . Попытка изменить эти значения с помощью chmod/chown вернет успех, но безрезультатно.

Когда клиент и сервер согласовывают расширения Unix, файлам и каталогам будут назначены uid, gid и режим, предоставляемые сервером. Поскольку монтирования CIFS, как правило, являются однопользовательскими, и одни и те же учетные данные используются независимо от того, какой пользователь обращается к монтированию, вновь созданные файлы и каталоги, как правило, получают право владения, соответствующее любым учетным данным, использованным для монтирования общего ресурса.

Если используемые uid и gid не совпадают на клиенте и сервере, могут быть полезны параметры forceuid и forcegid .

Если я правильно понял, клиент и сервер (при правильной настройке) могут игнорировать uid= и использовать права собственности, хранящиеся на сервере. В этом случае это актуально:

forceuid
указывает клиенту игнорировать любой uid, предоставленный сервером для файлов и каталогов, и всегда назначать владельцем значение параметра uid= .

Похоже, эта строка в fstab может работать лучше для вас:

//windows-ip/share-folder \
/home/mysuer/testmount \
cifs \ 
forceuid,uid=NUMBER,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

Затем вы монтируете с помощью sudo (или добавляете опцию user если она вам действительно нужна). Без опции noauto ОС попытается автоматически смонтировать общий ресурс при загрузке. Сеть может быть еще не доступна в то время, я не знаю, решит ли это ваша ОС. С systemd вы можете использовать x-systemd.automount, четвертое поле будет начинаться с:

x-systemd.automount,x-systemd.idle-timeout=1min,forceuid,uid=NUMBER,…

Альтернатива - autofs.